ext4：我的空闲空间去哪儿了？

Question

我刚刚将我的 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 可用空间舍入，最多 .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 用户身份登录，所以我知道我应该能够使用保留空间（这不是一个好主意，但只是作为一个原则）。

知道这里发生了什么吗？它是否与（以及如何）在发行版升级或/usrMageia 3 中的迁移期间发生的数据大小和文件创建/删除方面的大量磁盘更改相关（以及如何）（不知道为什么，因为/usr在与/（不是单独的分区）？

Answer 1

您正在使用保留块 count ，并尝试通过 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 为单位检查大小，它是四舍五入的，误差要小得多。