我们正在使用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 这不是由于为root保留块，显然与free inode无关。
我读了很多讨论，但没有发现可以应用于我们的案件。
这个问题发生在具有11GB虚拟磁盘的虚拟机上。 当使用10GB文件作为环回FS时，我们也看到了相同的行为。 我们正在使用RedHat 6（linux 2.6.32）。
我们的软件以root身份运行。 我也尝试了一个简单的cat / dev / zero> testfile，它停在相同的限制下，剩下16MB空闲空间。
任何帮助，将不胜感激。
编辑：在2个不同的系统上使用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
在Debiantesting盒（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个保留区块是什么吗？
谢谢。
几乎所有的文件系统，包括ext4，都为其元数据，日志和片段处理保留了一些空间。 您可能会看到该保留/无法使用的空间的影响。
无论如何，运行真正的100％利用率的文件系统是一个非常糟糕的主意。 始终为健康的文件系统保留一些可用空间。
更新：这是来自内核邮件列表的一个引用，解释为什么正好有4096个块被用于文件系统的使用：
这就是保留空间的地方。 在安装文件系统时，我们将文件系统空间（2％或4096个群集，以较小者为准）进行分割，然后将其用于上述情况，以防止代价高昂的零或意外的ENOSPC。
保留簇的数量可以通过sysfs来设置，但不能大于文件系统中空闲簇的个数。
/dev/sdd1 11G 11G 16M 100% /opt/HIDDEN/storage/raw_2
100％全额表示100％全额。 除非100％以内，否则没有更多可写入此分区。 我会冒险猜测，16MB的可用空间是零碎的可用空间，而不是实际上连续的。