The change was deliberate, because under some extreme circumstances you could end up corrupting the file system image when resize2fs aborted in the middle of a shrink operation. This tends to make some users cranky when they lose their data.
If you had bothered to read the entire git commit description, you would have gotten a lot more context:
resize2fs: refine minimum required blocks for flex_bg file systems
The previous commit exposed bugs in the calculation for flex_bg file
systems. The problem is that since (by default) we keep the metadata
blocks for the flex_bg in the first block group of the flex_bg, and
because we don't want to overwrite metadata blocks used by the
original file system with data blocks make life easier in case the
resize is aborted for some reason, we need to treat all of the
metadata blocks in the existing flex_bg has in use for the purposes of
calculate_minimum_resize_size().
Even though this means we need to reserve more data blocks to avoid
running out of space, the net result of these two commits is a net
savings in how much we can shrink a file system.
Note that using resize2fs -M multiple times will result in a file system which is *not* optimized for speed. In fact, it can be really bad for slow devices, such as CD-ROM's and Amazon Elastic Block devices, since files and directories will end up getting fragmented and where the data blocks can end up getting placed farther than optimal from the inode table locations.
The change was deliberate, because under some extreme circumstances you could end up corrupting the file system image when resize2fs aborted in the middle of a shrink operation. This tends to make some users cranky when they lose their data.
If you had bothered to read the entire git commit description, you would have gotten a lot more context:
resize2fs: refine minimum required blocks for flex_bg file systems
The previous commit exposed bugs in the calculation for flex_bg file minimum_ resize_ size().
systems. The problem is that since (by default) we keep the metadata
blocks for the flex_bg in the first block group of the flex_bg, and
because we don't want to overwrite metadata blocks used by the
original file system with data blocks make life easier in case the
resize is aborted for some reason, we need to treat all of the
metadata blocks in the existing flex_bg has in use for the purposes of
calculate_
Even though this means we need to reserve more data blocks to avoid
running out of space, the net result of these two commits is a net
savings in how much we can shrink a file system.
Using the following test sequence:
mke2fs -F -t ext4 /tmp/foo.img 2T
resize2fs -M /tmp/foo.img
resize2fs -M /tmp/foo.img
resize2fs -M /tmp/foo.img
Here is the comparison in the resulting file systems between the old
and new resize2fs (units are in 4k blocks):
old resize2fs 1117186 45679 43536
new resize2fs 48784 37413 37392
Signed-off-by: "Theodore Ts'o" <email address hidden>
Note that using resize2fs -M multiple times will result in a file system which is *not* optimized for speed. In fact, it can be really bad for slow devices, such as CD-ROM's and Amazon Elastic Block devices, since files and directories will end up getting fragmented and where the data blocks can end up getting placed farther than optimal from the inode table locations.