resize2fs allows resize beyond maximum fs size - corrupts fs

[Neil Wilson]

If you resize a 1G partition to more than 1T the filesystem becomes corrupted offline and errors on-line.

resize2fs does not check the maximum size of the filesystem before initiating the resize.

To reproduce:

$ dd if=/dev/zero of=tiny bs=1 count=0 seek=1G
$ mkfs.ext4 -F -J size=128 tiny

....
Maximum filesystem blocks=268435456
....
$ cp tiny xxl
$ resize2fs xxl 1310720M

resize2fs 1.42 (29-Nov-2011)
Resizing the filesystem on xxl to 335544320 (4k) blocks.
The filesystem on xxl is now 335544320 blocks long.

$ e2fsck xxl
e2fsck 1.42 (29-Nov-2011)
e2fsck: Group descriptors look bad... trying backup blocks...
One or more block group descriptor checksums are invalid. Fix<y>?

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: e2fsprogs 1.41.14-1ubuntu3
ProcVersionSignature: Ubuntu 3.0.0-16.29-generic 3.0.20
Uname: Linux 3.0.0-16-generic x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
CheckboxSubmission: 55cafa5b8b82ed224cc59d444cb1fc25
CheckboxSystem: 3e53d3ea5811723345f19eff5070f9ab
Date: Thu Mar 15 13:51:37 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
SourcePackage: e2fsprogs
UpgradeStatus: No upgrade log present (probably fresh install)

[Neil Wilson (neil-aldur)]

The use case here is expansion of the root partition of a virtual machines from a small core image.

[Neil Wilson (neil-aldur)]

Similarly with online resizing:

$ cp tiny xxl
$ dd if=/dev/zero of=xxl bs=1 count=0 seek=1310720M
$ sudo losetup /dev/loop0 xxl
$ sudo e2fsck /dev/loop0
e2fsck 1.42 (29-Nov-2011)
/dev/loop0: clean, 11/65536 files, 12635/262144 blocks
$ sudo mount /dev/loop0 /mnt
$ sudo resize2fs /dev/loop0
resize2fs 1.42 (29-Nov-2011)
Filesystem at /dev/loop0 is mounted on /mnt; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 80
Performing an on-line resize of /dev/loop0 to 335544320 (4k) blocks.
resize2fs: Operation not permitted While trying to add group #8192

$ sudo umount /dev/loop0
$ sudo e2fsck /dev/loop0
e2fsck 1.42 (29-Nov-2011)
/dev/loop0: clean, 11/67108864 files, 4220121/268435456 blocks

With online resizing the filesystem fails to a consistent state at the maximum filesystem size.

[Theodore Ts'o (tytso)]

Yep, confirmed; normally users don't specify a size explicitly, and simply allow resize2fs to use the size of the block device as the size to use for the new file system --- and we have the appropriate tests in that code path.

But if the user specifies the size explicitly, we aren't checking to make sure the new size is too large. That's a bug, although most users (hopefully) won't try to explicitly set a new file system size, which is why no one has noticed up until now. So I wouldn't give this a very high level of importance from a distro perspective, but it's something that I will get fixed in the next release.

[Neil Wilson (neil-aldur)]

I should point out that the resize2fs in precise does the same thing even if you don't specify the size:

For example do

$ cp tiny xxl
$ dd if=/dev/zero of=xxl bs=1 count=0 seek=1310720M
$ resize2fs xxl

When I looked at the code I couldn't see an explicit check in there.

[Neil Wilson (neil-aldur)]

Similarly with lvm and kpartx

Although on something with big enough real disks I only have:

resize2fs 1.41.12 (17-May-2010)

[Theodore Ts'o (tytso)]

Yes, sorry, there are two different problems here. The one I was talking about happens when you go above 16TB. That fix is easy.

Going to a fs size a little greater than 1TB is triggering another problem from a file system originally created with 1G file size, which I've replicated and I've confirmed that it's taking place on 1.42.x as well as e2fspros 1.41.x. The problem is that when we run out of reserved GDT blocks, resize2fs isn't noticing and ends up corrupting the file system.

The workaround for now is to explicitly create the file system with an expected maximum resize: mke2fs -t ext4 -E resize=8T /dev/tiny

You'll need to do this if you want to resize to succeed in any case. I agree resize2fs should notice this case and deal with it more intelligently.