Comment 17 for bug 1798562

Thanks for the very nice repro! I've created a fix which will be going into the maint branch of the e2fsprogs tree. The commit description:

    resize2fs: update checksums in the extent tree's relocated block

    When shrinking an file system, and we need to relocate an inode, the
    checksums in its extent tree must get updated to reflect its new inode
    number. When doing this, we need to do this *after* we update the
    extent tree to reflect any blocks which need to be relocated due to
    the file system shrink operation.

    Otherwise, in the case where only an interior node of the extent tree
    needs to get relocated, and none of the entries in that node need to
    be adjusted, the checksum for that interior node is updated in the old
    copy of that block, and then after the extent tree is updated to use
    the new copy of that interior node, the extent tree is left with an
    invalid checksum.

    This is a relatively rare case, since it requires the following
    conditions to be true:

    *) The metadata checksum feature must be enabled.
    *) An inode needs to be relocated.
    *) The inode needs to have an interior node.
    *) The block for that interior node needs to be relocated.
    *) None of blocks addressed by entries in that interior node needs
        to be relocated.

    When all of these conditions are true, though, the file system is left
    with corrupted with bad checksum for the extent tree block.

    Addresses-Launchpad-Bug: 1798562

    Signed-off-by: Theodore Ts'o <email address hidden>
    Reported-by: Jean-Baptiste Lallement <email address hidden>

I've tested e2fsprogs with this change and it fixes your repro. I also have a regression test in the subsequent commit which reproduces the problem with a smaller test file system.