在缩小 ext4 文件系统后，resize2fs M我安装了它，发现它只使用了 57%。所以我跑了
$ resize2fs -d 32 -M rootfs-2021-06-28.img
resize2fs 1.44.5 (15-Dec-2018)
fs has 9698 inodes, 1 groups required.
fs requires 115683 data blocks.
With 1 group(s), we have 16352 blocks available.
Added 4 extra group(s), blks_needed 115683, data_blocks 147424, last_start 30686
Last group's overhead is 16416
Need 84997 data blocks in last group
Final size of last group is 101413
Estimated blocks needed: 232485
The filesystem is already 232485 (4k) blocks long. Nothing to do!
我猜想 115683 个数据块加上 16416 个开销就是 232485 的 57%，但我无法将这些数字加起来为 232485 个块。说实话，我不太明白这个计算过程。手册页承认
已知错误
resize2fs 估计的文件系统的最小大小可能不正确，特别是对于具有 1k 和 2k 块大小的文件系统。
但我有 4k 块大小。
如果resize2fs对于少量块来说这是错误的工具，请推荐一种不同的方法来缩小文件系统。
答案1
正如这里所解释的，使用的间接费用裕度很大：
另请参阅链接的 C 代码以了解详细信息。
为了更直观地看到它，我使用 1G 图像文件做了一个小测试，用越来越少的数据填充它一个文件并resize2fs -M在其上使用：
从数据文件 900M 减少到 600M 估计大小为多于分区的大小。
- 900M：预计需要的块：440607（1.68G）
- 800M：预计需要的块：382239（1.46G）
- 700M：预计需要的块：323871（1.24G）
- 600M：预计需要块：298271（1.14G）
500M及以下
- 500M：预计需要的块：239903（937M）
- 400M：预计需要的块：181534（709M）
- 300M：预计需要的块：123166（481M）
- 200M：预计需要的块：64798（253M）
- 100M：预计需要的块：39198（153M）
诸如此类的工具在幕后gparted使用。resize2fs制作一个分区填充一种方法是创建所需大小的新图像文件并将数据移至那里。一个人当然需要空间来工作。
否则使用-f(force) 标志并使用：
resize2fs -d 32 -f file.img NEW_BLOCK_COUNT
-f Forces resize2fs to proceed with the filesystem resize operation, overriding some safety checks which resize2fs normally enforces.