さて、これは iPad Pro に関することですが、皆さんに質問しているのは、これは iOS/OS X の基盤となる Unix システムに関することであり、iPad に限ったことではないからです。(そして、まず「デバイスに空き容量がない」という件について、関連する StackExchange の記事をすべて何時間もかけて読みました。)
問題 1:2〜8MB を超えるファイルを作成できません (再起動すると変化します)。これにより、iPad が実質的に使用できなくなります。多くのアプリが起動しない、アプリがインストールされないなど、空き容量が数ギガあるにもかかわらず、奇妙な 2 ～ 8 MB の制限を超えるファイルを作成しようとすると、「デバイスに空き容量がありません」と報告されます。
問題2:ディスク容量がどんどん減っていく. アプリをアンインストールし続けました (この「デバイスに空き容量がありません」という問題が発生する前に)。そして、いくつ削除しても、数日後にはいっぱいになったように見えました。最初は空き容量が 1 GB のときにいっぱいになったように見えました。その後、数週間かけて 2 GB、3...4...6...8... と増え、最終的には空き容量が 9 GB になっても、デバイスはいっぱいになったように見えました。そのため、何十 GB ものアプリをアンインストールしていたので、膨大なディスク容量が未計算になっていることがわかりました。
きっかけとなった事件: 数か月前、ディスク容量が本当に少なくなり、一度に複数のアプリを更新しようとしたときに、悲惨なことが起こりました。iPad がフリーズし、いくつかのシステム データベースが破損し、iPad が特定のパスワードの再設定を求め始めました。それ以来、さまざまな問題が発生しましたが、ほとんど使用できました。先週までは!
私はもう限界で、解決できないならデバイスを消去するしかないので、iPadを脱獄することにしました。「du -h -d 1」不足している約 60 GB のスペースを消費していたものが何なのかを確認します。
私はドライブ上でfsck_hfsを実行しました（これは信じられないほど困難でした!!）そして確かに、次のようなメッセージが表示されました。200万ブロックが空いている - 1600万ブロックになるはず計算してみると、完璧に納得できました！fsckが完了して再起動すると、突然、失われたスペースが戻ってきて、71GB無料！
しかし、その頃は問題がひどくなり、2〜8MB を超えるファイルを作成できなくなりました。私は文字通り次のコマンドを実行しました:
dd if=/dev/zero of=testfile.bin bs=1M count=10
..そして、ほとんどの場合、2 の完全な MiB 累乗 (2、4、または 8MiB など) である特定の数値で失敗し、「デバイスに空き容量がありません」というメッセージが表示されます。ただし、そのサイズのファイルを必要なだけ書き込むことはできます。今日の制限は 4.0MiB だとします。増分ファイル名を使用して、DD コマンドを何度も実行できます。7 回連続で実行して 7 つのファイルを作成しましたが、毎回完璧に機能しました。4.1MiB にすると失敗します。7x4 (32MiB) のファイルを作成したばかりなのにです。
それでも、ディスク容量は勝手に減り続け、今朝は空き容量が 39 GB まで減っています。もう一度 fsck_hfs を実行すると、空き容量は約 70 GB に戻り、再び徐々に減少し始めます。
困惑しています。数十 GB の空き容量があるのに、デバイスが「デバイスに空き容量がありません」というエラーを表示するのはなぜですか?iPad にはディスクが 1 つしかなく、4GB の /System パーティションと残りが /private/var に分かれています。私のシステム パーティションは 75% しか使用されていませんが、これはどの iOS デバイスでも正常です。
df で inode をチェックしたところ、データ ディスク (/dev/disk0s1s2) には 40 億個ほどの inode が空いていました。
以下は関連するプリントアウトです（さまざまな日付から）：
iPad:/private root# df
Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on
/dev/disk0s1s1 9316200 6795912 2427128 74% 125137 4294842142 0% /
devfs 99 99 0 100% 172 0 100% /dev
/dev/disk0s1s2 486135960 476137152 9998808 98% 1217291 4293749988 0% /private/var
iPad:/private root# df -h
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk0s1s1 4.4Gi 3.2Gi 1.2Gi 74% 125137 4294842142 0% /
devfs 50Ki 50Ki 0Bi 100% 172 0 100% /dev
/dev/disk0s1s2 232Gi 227Gi 4.8Gi 98% 1217291 4293749988 0% /private/var
iPad-Pro-256GB:/sbin root# mount
/dev/disk0s1s1 on / (hfs, local, journaled, noatime)
devfs on /dev (devfs, local, nobrowse)
/dev/disk0s1s2 on /private/var (hfs, local, nodev, nosuid, journaled, noatime, protect)
iPad-Pro-256GB:~ root# pwd
/var/root
iPad-Pro-256GB:~ root# dd if=/dev/zero of=test3.bin bs=1M count=20
dd: error writing 'test3.bin': No space left on device
9+0 records in
8+0 records out
8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.671137 s, 12.5 MB/s
デバイスの空き容量が約 9GB だったが、実際には 70GB の空き容量が必要だったときに実行した最初の fsck_hfs の抜粋:
** Checking volume bitmap.
Volume bitmap needs minor repair for orphaned blocks
Volume bitmap needs repair for under-allocation
** Checking volume information.
Invalid volume free block count
(It should be 16884367 instead of 2063604)
完全に成功した fsck_hfs:
iPad-Pro-256GB:/ root# umount -f /private/var && killall backboardd && fsck_hfs -f -y /dev/disk0s1s2
umount: /private/var: not currently mounted
iPad-Pro-256GB:/ root# fsck_hfs -f -y /dev/disk0s1s2
** /dev/rdisk0s1s2
Executing fsck_hfs (version hfs-366.30.3).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
The volume name is Data
** Checking extents overflow file.
** Checking catalog file.
Incorrect size for file MediaLibrary.sqlitedb
(It should be 1343488 instead of 1564672)
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
Volume bitmap needs minor repair for orphaned blocks
** Checking volume information.
Invalid volume free block count
(It should be 16972349 instead of 14633343)
** Repairing volume.
Limited repair mode, not all repairs available
** Rechecking volume.
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
The volume name is Data
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** Trimming unused blocks.
** The volume Data was repaired successfully.
ノート：
A. 大きなファイルの作成に失敗した場合、syslog には何も表示されません。
B. デバイス: iPad Pro 9.7" 256GB iOS 10.2.1 HFS (10.3 で後から導入された APFS ではありません)。この問題が発生するまで、ジェイルブレイクしたことはありませんでした。
答え1
ファイルシステムが非常に断片化されている場合、空き領域はたくさんあるものの、大きなブロックには十分な領域がない可能性があります。
あなたのケースでは、ファイルシステム上でこれが当てはまる可能性があるようです。
断片化は通常、多数の小さなファイルをファイルシステムにコピーし、これらの小さなファイルのランダムな部分を削除すると発生します。これにより、より大きなブロックに再結合できない断片が解放されます。
以前は、usenet news多数の記事を個人のディスクにコピーし、さまざまなニュースグループに異なる保存時間を使用した場合、ファイルシステムは通常この問題に悩まされていました。
このファイルシステム用のデフラグツールがない場合は、多数の小さなファイルをファイルシステム内の別の場所にコピー (移動ではなく) し、小さなファイルの古いバージョンを削除します。この操作中に適切なファイルを取得できれば、解放されたフラグメントが組み合わさって、新しい大きな空きブロックが作成される可能性が高くなります。