好的，這是在 iPad Pro 上，但我問你們是因為這是關於 iOS/OS X 背後的底層 Unix 系統，而不是 iPad 特定的。（是的，我先花了幾個小時閱讀所有相關的 StackExchange 中關於「設備上沒有剩餘空間」的內容。）
問題#1：我無法建立大於 2-8MB 的檔案（重啟後會有所不同）。這使得 iPad 幾乎無法使用。許多應用程式無法啟動，應用程式無法安裝等。當您嘗試建立大於奇怪的 2-8MB 限制的檔案時，儘管有大量可用空間，但會報告「裝置上沒有剩餘空間」。
問題#2：磁碟空間不斷消失。我不斷卸載應用程式（在出現“設備上沒有空間”問題之前），無論我刪除了多少應用程序，幾天后它都會顯示為滿。起初，它的可用空間為 1GB。然後幾週後，它最終變成了 2GB，然後是 3...4...6...8...，最終即使有 9GB 可用空間，該設備仍然表現得好像已滿！所以我知道，由於我卸載了數十個應用程序，因此有大量磁碟空間下落不明。
突發事件：幾個月前發生了一些災難性的事情，當時我的磁碟空間非常低，並嘗試同時更新多個應用程式。 iPad 從那時起，幾個系統資料庫被損壞，iPad 開始要求我重新設定某些密碼，等等。直到上週！
我最終對 iPad 進行了越獄，因為我已無計可施，如果我無法解決它，就必須擦除該設備，而且我絕對渴望運行一個“杜-h-d 1”看看到底是什麼消耗了大約 60GB 的缺失空間！
我在驅動器上運行了 fsck_hfs（這非常困難！！），果然，它說了類似的話200 萬塊空閒 - 應該是 1600 萬塊，我做了數學計算，結果很有意義！ fsck 完成並重新啟動，然後 BAM！突然之間，我失去的空間又回來了，我擁有了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) 的檔案！
儘管如此，磁碟空間仍繼續自行縮小，今天早上已降至 39GB 可用空間。如果我再次對其進行 fsck_hfs，它將回到 ~70GB 的可用標記，並再次開始慢慢減少。
我不知所措。只是當有數十 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
摘自我運行的第一個 fsck_hfs，當時設備有大約 9GB 可用空間，但本應有 70GB 可用空間：
** 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.
筆記：
答：當大檔案建立失敗時，系統日誌上沒有任何相關內容。
B. 裝置：iPad Pro 9.7" 256GB iOS 10.2.1 HFS（不是 10.3 稍後引入的 APFS）。在此問題出現很久之後才越獄。
答案1
如果檔案系統碎片非常多，則可能有大量可用空間，但較大的區塊中沒有足夠的空間。
您的情況看起來好像這在您的檔案系統上是正確的。
如果將大量小檔案複製到檔案系統，然後刪除這些小檔案的隨機部分，通常會發生碎片。這會釋放無法重新組合成更大塊的片段。
以前，usenet news如果您將大量文章複製到私人磁碟並為各個新聞群組使用不同的保留時間，檔案系統通常會遇到此問題。
如果該檔案系統沒有碎片整理工具，您可以將大量小檔案複製（而不是移動）到檔案系統中的另一個位置，然後刪除舊版本的小檔案。如果您在執行此操作時獲得了正確的文件，則釋放的片段很有可能會組合在一起以創建新的更大的空閒區塊。