resize2fs does not respect flex_bg

[Phillip Susi]

Binary package hint: e2fsprogs

When running resize2fs to perform an online extend of an ext4 filesystem, it does not respect the flex_bg feature. Instead, it lays out the added block groups with their normal non flex_bg positions.

[Theodore Ts'o (tytso)]

This is a true statement. Getting this right will require kernel support as well as changes to e2fsprogs, since the kernel ioctl used by online resize currently assumes that the blocks used for the allocation bitmaps, et. al, are in the block group which is added.

This shortcoming isn't really user-visible, although it will cause barely noticeable performance differences for resized filesystems versus file systems that were originally created at that size. It will also impact fsck time somewhat. It's a known problem, but it's relatively low priority to fix.

[Phillip Susi (psusi)]

Adding kernel task then and marking as triaged and low priority.

[Phillip Susi (psusi)]

You haven't happened to fix this in the last 8 years have you Ted? ;)

[Theodore Ts'o (tytso)]

Yes, this has been fixed quite a while ago. :-)

Online resize with flex_bg was fixed in 2012 --- call with the v3.10 kernel or so.

Offline resize was fixed around that time (e2fsprogs 1.43), but there have been some bugs with flex_bg and off-line resizing, so I'd recommend using at least e2fsprogs 1.44.x if you want to off-line resize file systems with flex_bg. And on-line resizing is actually going to be safer in general --- mainly because it's less capable --- the scary bits with off-line resizing are things that on-line resize can't do, like shrink the file system or move the inode table around to make room for more block group descriptors than were originally reserved at mkfs time.