cannot resize ext4 once GDT blocks exhausted

[Robert Citek]

With an ext4 filesystem, you can shrink and expand a filesystem until you run out of GDT blocks. After that the filesystem cannot be resized, neither shrunk nor expanded, even if unmounted.

Although this issue is most relevant in an LVM environment, here's some code to demonstrate the issue using a loopback device. The code needs to be run as root.

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

At this point resize2fs returns an error:

resize2fs: /dev/loop0: The combination of flex_bg and
       !resize_inode features is not supported by resize2fs.

This means the filesystems is 5GB forever. It cannot be resized,
expanded or shrunk.

In contrast, ext3 does not have this issue.

mkfs.ext3 ${dev} 5M
tune2fs -l ${dev} | grep -i gdt
resize2fs ${dev} 3G
tune2fs -l ${dev} | grep -i gdt
resize2fs ${dev} 2G
tune2fs -l ${dev} | grep -i gdt
resize2fs ${dev} 3G
tune2fs -l ${dev} | grep -i gdt
resize2fs ${dev} 5G
tune2fs -l ${dev} | grep -i gdt
resize2fs ${dev} 3G

Workaround: when creating an ext4 filesystem, use the extended option resize=. For example:

mkfs.ext4 -E resize=100000000000 ${dev} 5M
tune2fs -l ${dev} | grep -i gdt
resize2fs ${dev} 5G
tune2fs -l ${dev} | grep -i gdt
resize2fs ${dev} 3G

This option can be added to /etc/mke2fs.conf.

This is on Ubuntu Lucid 10.04 with the latest updates.

# lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04

# dpkg -l | awk '/e2fsprogs/ {print $2, $3}'
e2fsprogs 1.41.11-1ubuntu2

# uname -rvmpio
2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686 unknown unknown GNU/Linux

# cat /proc/version_signature
Ubuntu 2.6.32-25.44-generic 2.6.32.21+drm33.7

Regards,
- Robert

[Robert Citek (robert-citek)]

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

[Theodore Ts'o (tytso)]

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.

[Robert Citek (robert-citek)]

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.

[Robert Citek (robert-citek)]

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

[Launchpad Janitor (janitor)]

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

[First Last (junkthisis)]

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 :(