我们使用 ext4 文件系统将数据存储在一个大文件中。
我们遇到了一个奇怪的问题：df 报告可用空间（16MB），dumpe2fs 报告 4096 个可用块（4KB，与 df 报告的内容相符），但是当尝试将数据附加到我们的文件时，系统报告设备上没有剩余空间。
[root@localhost raw_2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdd1 11G 11G 16M 100% /opt/HIDDEN/storage/raw_2
[root@localhost raw_2]# df -i .
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdd1 11264 12 11252 1% /opt/HIDDEN/storage/raw_2
[root@localhost raw_2]# echo test > testfile
-bash: echo: write error: No space left on device
[root@localhost storage]# umount /dev/sdd1
[root@localhost storage]# dumpe2fs -h /dev/sdd1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name: <none>
Last mounted on: /opt/HIDDEN/storage/raw_2
Filesystem UUID: 9d6ca417-0854-461d-993d-e23c2a2229d4
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 11264
Block count: 2883580
Reserved block count: 0
Free blocks: 4096
Free inodes: 11251
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 703
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 128
Inode blocks per group: 8
Flex block group size: 2048
Filesystem created: Tue Nov 15 11:32:52 2016
Last mount time: Tue Dec 6 14:14:57 2016
Last write time: Tue Dec 6 15:16:54 2016
Mount count: 8
Maximum mount count: 32
Last checked: Tue Nov 15 11:32:52 2016
Check interval: 15552000 (6 months)
Next check after: Sun May 14 12:32:52 2017
Lifetime writes: 3572 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
Default directory hash: half_md4
Directory Hash Seed: dc8da308-ef45-4bea-b156-5690eb399646
Journal backup: inode blocks
Journal features: (none)
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0004a45b
Journal start: 0
这不是由于为根保留的块，显然与空闲的 inode 无关。
我读过很多讨论，但发现没有任何内容适用于我们的情况。
此问题发生在具有 11GB 虚拟磁盘的 VM 上。当使用挂载为环回 FS 的 10GB 文件时，我们也看到了同样的行为。我们使用的是 RedHat 6 (linux 2.6.32)。
我们的软件以 root 身份运行。我还尝试了一个简单的 cat /dev/zero > testfile，它停在了相同的限制处，留下了 16MB 的可用空间。
任何帮助，将不胜感激。
编辑：在两个不同的系统上使用 statfs 会出现奇怪的行为。
在我的原始系统上，statfs 没有报告任何差异 f_bfree==f_bavail ：
statfs("/opt/HIDDEN/storage/raw_1/", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=2882680, f_bfree=2665715, f_bavail=2665715, f_files=11264, f_ffree=11251, f_fsid={-2032429898, 1911081970}, f_namelen=255, f_frsize=4096}) = 0
在 Debian 测试机（Linux 4.8.0）上：
statfs("/home/", {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=55137925, f_bfree=26426280, f_bavail=26422184, f_files=10114944, f_ffree=9685471, f_fsid={1010187930, 3946494061}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
此 fs 没有保留块，但 f_bavail（非特权用户可用的空闲块）和 f_bfree（fs 中的空闲块）之间有 4096 个块的差异。有人知道这 4096 个保留块是什么吗？
谢谢。
答案1
几乎所有文件系统（包括 ext4）都为其元数据、日志和片段处理保留了一些空间。您可能会看到该保留/不可用空间的影响。
无论如何，运行一个真正利用率为 100% 的文件系统是一个非常糟糕的主意。总是为健康的文件系统保留一些可用空间。
更新：这是来自内核邮件列表解释为什么恰好 4096 个块被保留用于文件系统：
这就是预留空间发挥作用的地方。在安装文件系统时，我们会切出一小部分文件系统空间（2% 或 4096 个簇，以较小者为准），然后将其用于上述情况，以防止代价高昂的零输出或意外的 ENOSPC。
保留簇的数量可以通过 sysfs 设置，但它永远不会大于文件系统中可用簇的数量。
答案2
/dev/sdd1 11G 11G 16M 100% /opt/HIDDEN/storage/raw_2
100% 满意味着 100% 满。在低于 100% 之前，无法向此分区写入任何内容。我大胆猜测，16MB 的可用空间是碎片化的可用空间，实际上并不连续。