我刚刚将 Mageia 2 64 位 VM 升级到 Mageia 3，现在我的虚拟磁盘可用空间几乎为零，尽管空间使用率还不到 100%。
我不是 ext4 文件系统专家，但我已经提取了我能想到的所有相关信息：
命令输出df -h /（：
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 11G 9.9G 0 100% /
以防万一，没有-h选项的相同输出：
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10645080 10353564 0 100% /
现在有-i选项：
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 670K 338K 332K 51% /
根据我的理解，我应该有：
-11G - 9.9G = 1.1G 可用空间进行舍入，最多 0.1G 误差范围，或
-11G - 9.9G - .05 * 11G = 0.55G （采用保留块）考虑的百分比（在我的例子中为 5% - 默认分配选项）
我什至无法创建任何文件。
另外，自从我第一次遇到“没有可用空间”问题以来，我已经删除了 300-500 MB 的文件，但可用空间仍然显示 0，尽管此后我被拒绝创建任何文件（以 root 身份登录）！我还多次重新启动系统以解决删除时可能仍处于打开状态的已删除文件，但报告的可用空间没有变化。最后，自从第一次出现问题以来，正常运行时间最多为 12 小时，并du -h /var/log提供了 38M，因此这里没有日志疯狂。
输出的第一行dumpe2fs给出：
dumpe2fs 1.42.7 (21-Jan-2013)
Filesystem volume name: <none>
Last mounted on: /sysroot
Filesystem UUID: 45b03008-87fa-4684-a98a-bd5177e2b475
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 685440
Block count: 2737066
Reserved block count: 136853
Free blocks: 88348
Free inodes: 339326
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 668
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8160
Inode blocks per group: 510
Flex block group size: 16
Filesystem created: Mon Aug 20 12:34:41 2012
Last mount time: Wed May 29 14:29:19 2013
Last write time: Wed May 29 14:09:03 2013
Mount count: 44
Maximum mount count: -1
Last checked: Mon Aug 20 12:34:41 2012
Check interval: 0 (<none>)
Lifetime writes: 66 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 46157
Default directory hash: half_md4
Directory Hash Seed: bc061f51-9d12-4851-a428-6fb59984118b
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00015d7c
Journal start: 17427
最后，我尝试使用保留块计数以防万一，这是输出：
命令：tune2fs -m 0 /dev/sda1 && /usr/bin/df / && tune2fs -m 5 /dev/sda1 && /usr/bin/df /
tune2fs 1.42.7 (21-Jan-2013)
Setting reserved blocks percentage to 0% (0 blocks)
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10645080 10353576 291504 98% /
tune2fs 1.42.7 (21-Jan-2013)
Setting reserved blocks percentage to 5% (136853 blocks)
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10645080 10353576 0 100% /
显然，通过将保留块百分比设置为 0，我可以恢复大约 285M，但这与最坏情况的数学不匹配，包括我所理解的保留块百分比：11G - 9.9G - .05 * 11G = 0.55G。也没有告诉我为什么删除 300~500M 文件后我仍然无法创建任何文件并且可用空间显示为“0”。请记住，无论如何，我都是以 root 身份登录的，所以我知道我应该能够使用保留的空间（这不是一个好主意，但只是作为一个原则）。
知道这里发生了什么吗？它是否与发行版升级或 Mageia 3 中的迁移期间发生的数据大小和文件创建/删除方面发生的大量磁盘变化有关（以及如何）/usr（不明白为什么，因为/usr在相同的文件系统上/（不是一个单独的分区）？
答案1
你正在玩保留块数，并尝试通过免费控制它空间在具有四舍五入值的 df 内。
10645080-10645080*0.05=10112826 blocks are available for normal user
并且您已经使用了 10353576 个块，因此这是正常的。
还df对值进行舍入。你有 10645080 个 1K 块，四舍五入为 11G。
实际上是10645080/1024/1024=10.15G，而不是11G。
您可以运行df -BM以 MB 为单位检查大小，它是四舍五入的，误差要小得多。