resize2fs: Illegal indirect block found while trying to resize

[Jeffy.Chen]

The new resize2fs(1.43+) failed to resize attached image file, and e2fsck didn't report any error before the resizing.

Test steps:
1/ e2fsck -fy userdata.img
2/ resize2fs userdata.img 220M

Result:
When using resize2fs from e2fsprogs 1.43+(tested 1.43.4/1.43.5/1.44.4), it would abort with:
Resizing the filesystem on userdata.img to 225280 (1k) blocks.
resize2fs: Illegal indirect block found while trying to resize userdata.img
Please run 'e2fsck -fy userdata.img' to fix the filesystem
after the aborted resize operation.

More information:
1/ The image is generated on xenial with genext2fs
2/ It works well on xenial with e2fsprogs 1.42.13-1ubuntu1
3/ It works well when resizing with a size less than 220M, for example "resize2fs userdata.img 219M"
4/ online resize works

[Theodore Ts'o (tytso)]

Yep, I can reproduce the problem. It bisected to:

commit 538ef363261b4f851ca69f342336aa896e24eb27 (refs/bisect/bad)
Author: Darrick J. Wong <email address hidden>
Date: Sun Dec 14 22:13:09 2014 -0500

    resize2fs: don't play stupid games with the block count

    While it may be true that playing games with old_fs' block count
    during a grow operation shuts up a bunch of warnings, resize2fs
    doesn't actually expand the group descriptor array to match the size
    we're artificially stuffing into old_fs, which means that if we
    actually need to allocate a block out of the larger fs (i.e. we're in
    desperation mode), ext2fs_block_alloc_stats2() scribbles on the heap,
    leading to crashes if you're lucky and FS corruption if not.

    So, rip that piece out and turn off com_err warnings properly and add
    a test case to deal with growing a nearly full filesystem.

    Signed-off-by: Darrick J. Wong <email address hidden>
    Signed-off-by: Theodore Ts'o <email address hidden>

In the course of fixing the above bug, it means that if there was a need to grow file system which is nearly full, and the resize is being done off-line, and there is a need to grow the file system, we will end up failing as described in the bug.

This is a very rare set of circumstances, which is why it hadn't been noticed for three years. I'm curious how the bug reporter came across it. Also note that it's strongly recommended that online resize be used whenever possible, as this actually tends to be the much more well-tested path. It's a real bug, but it's going to be lower priority to fix.

[Jeffy.Chen (jeffy.chen)]

Hi Theodore,

Thanks for your reply.

Right, we were using "resize2fs -M" to shrink our images(so it's nearly full), then grow it at first boot after flashed to the embedded device.

And the online resize works perfectly, i'll use that :)

[Theodore Ts'o (tytso)]

Note a file system which is significantly shrunk --- which tends to be the case with resize2fs -M --- is going to have files fragmented which will have performance implications. It's not clear to me what you are trying to optimize for --- I assume you're just wanting to save on download bandwidth so you want a highly compressed image?

You might want to consider using a raw qemu image, e.g:

     e2image -Q /dev/sda1 /tmp/sda1.qcow
     bzip /tmp/sda1.qcow # optional

which can then be unpacked via:

     bunzip /tmp/sda1.qcow.bz2
     e2image -r /dev/sda1.qcow /dev/sda1

You can of course also use qemu-img from the qemu package. e2image -Q is a bit more efficient though since it will only include blocks which are in use in the file system, where as qemu-img is not aware of the underlying file system.