Comment 2 for bug 1796788

Theodore Ts'o (tytso) wrote :

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.