cannot resize ext4 once GDT blocks exhausted

Most likely e2fsprogs as tune2fs, mkfs.ext3, mkfs.ext4, and resize2fs are all components of that package.

Yes, this is a known restriction right now. Note that we reserve enough GDT blocks so you can grow the filesystem by a factor of 1024 of the initial size. So in practice the limitation is rather hard to hit except in rather extreme artificial test cases.

Yes, if you initially create a filesystem to be only a 1MB, and then grow it to be greater than 1GB, you'll lose. But that's not how most people should be using file system resizes.

If you *do* want to do this, for some kind of crazy installation system where you dd a CD-ROM image onto a disk and then resize it (which will result in really crappy filesystem layout) --- if you really want to do this crazy, insane, performance-destroying hack, you can manually control how many GDT blocks are reserved by using the resize extended parameter to mke2fs. See the mke2fs man page for more information.

The way we discovered this issue was by creating a small generic install of Ubuntu with an LVM containing several small LVs, creating an image of the install, and then pushing out the image to client machines. The full size of the image was < 1 GB with most of the LVs < 100 MB, which made pushing the image over a slow network very fast. Once on the client the PV was expanded as well as the LVs, and their corresponding filesystems were resized. It was at that point that we discovered we could not expand beyond a certain size. 100 MB * 1024 ~ 100 GB, which is not uncommon for drives these days. But what really surprised us was that we could not resize up or down with ext4 even when unmounted.

This isn't a show stopper for us. Now that we are aware of this limitation with ext4/resize2fs/tune2fs, we just have to rethink our strategy and redesign our images.

Just an FYI, using the resize= option in mkfs.ext4 was not intuitive. Sometimes the number of GDT blocks reserved was smaller when specifying a larger resize= number.

Instead we created an LV that was 1/1,000th our estimated maximum, created a filesystem on it with mkfs.ext4, and then resized it to the minimum. Here's a sample script using the loopback device:

dd if=/dev/zero of=ext4.img bs=1M count=10000
dev=$(losetup -vf ext4.img| cut -d" " -f4)
mkfs.ext4 ${dev}
tune2fs -l ${dev} | grep -i gdt
resize2fs -M ${dev}
tune2fs -l ${dev} | grep -i gdt

Regards,
- Robert

Status changed to 'Confirmed' because the bug affects multiple users.

can't resize my ext4 root file system and only linux file system (I only have one linux partition apart from swap partition). All I wanted was to go from 3 GB to 4 GB.

Resized the partition with gparted live but now the file system is stuck at 3 GB...

Lubuntu 12.04

cpo@tower-Lubuntu:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda6 2884798 2544180 186798 94% /
udev 990736 4 990732 1% /dev
tmpfs 399188 848 398340 1% /run
none 5120 0 5120 0% /run/lock
none 997968 168 997800 1% /run/shm
cpo@tower-Lubuntu:~$ sudo resize2fs /dev/sda6
resize2fs 1.42 (29-Nov-2011)
resize2fs: /dev/sda6: The combination of flex_bg and
 !resize_inode features is not supported by resize2fs.

Can anyone help? The only option I have now is to format partitions and do a clean install of Lubuntu :(