好的，这是在 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如果您将大量文章复制到私人磁盘并为各个新闻组使用不同的保留时间，文件系统通常会遇到此问题。
如果该文件系统没有碎片整理工具，您可以将大量小文件复制（而不是移动）到文件系统中的另一个位置，然后删除旧版本的小文件。如果您在执行此操作时获得了正确的文件，则释放的片段很有可能组合在一起以创建新的更大的空闲块。