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.
    
    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):
    
                    resize #1  resize #2   resize #3
    old resize2fs    1117186     45679       43536
    new resize2fs      48784     37413       37392
    
    Signed-off-by: "Theodore Ts'o" <[email protected]>

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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1415077

Title:
  resize2fs  -P minimum size  differs greatly between v1.42.10 and
  v1.42.9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1415077/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to