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パーティションを作成する充填材1つの方法は、必要なサイズの新しい画像ファイルを作成し、そこにデータを移動することです。確かに働くスペースが必要です。
-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.