resize2fs fails if new size is more than 1024 times larger than initial size and large inodes are used

[JPEWdev]

resize2fs will fail with the error:

./resize/resize2fs: Illegal doubly indirect block found while trying to resize temp.ext4
Please run 'e2fsck -fy temp.ext4' to fix the filesystem
after the aborted resize operation.

if the new size is more than 1024 times larger than the original size. This can be easily reproduced with the following script:

#! /bin/sh
rm -f temp.ext4
STARTSIZE=65536 # 64 MB
ENDSIZE=68157440 # 65 GB
dd if=/dev/zero of=temp.ext4 seek=$STARTSIZE count=0 bs=1024
./misc/mke2fs -F -b 4096 -I 256 -j -O extent,64bit,flex_bg temp.ext4
dd if=/dev/zero of=temp.ext4 seek=$ENDSIZE count=0 bs=1024
./resize/resize2fs temp.ext4

Note that removing flex_bg from the options, or using 128 byte inodes when creating the file system image will prevent it from failing.

[tytso]

It's fair this is a bug, however....; trying to resize a file system to 1024 times its original size is a positive anti-pattern. Don't do that. The file system is created with parameters that optimize it for a particular size, and sure, you can grow it by 2x, 5x, 10x the original size. and it'll do fine. The basic idea is creating a file system for a RAID array, and then growing it as you add more disks. But when you try to inflate a file system by 100x, 1000x, etc., this is not recommended.

There seems to be people who want to be able to dd a small image on to a large disk, and then inflate it to be 14TB, and even if it works, the file system is not going to be optimized for that large disk. It's a bad idea.

That's also why these use cases aren't as well tested as they should be --- because it's not something anyone sane should be doing in the first place!

It's something I will look at, but it's not high priority for me to fix, because you shouldn't be doing it in the first place!