commit 4b3038134baf81c6f9bd36dbbf565ea66e46331f
Author: Theodore Ts'o <email address hidden>
Date: Sat Oct 20 09:14:48 2018 -0400
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.
If you're up for downloading the latest maint branch from e2fsprogs and give it a try to see if it fixes your issue, since you have a reliable repro, I would really appreciate it. Thanks!!
This looks like a dup of https:/ /bugs.launchpad .net/ubuntu/ +source/ e2fsprogs/ +bug/1798562
and is fixed by:
commit 4b3038134baf81c 6f9bd36dbbf565e a66e46331f
Author: Theodore Ts'o <email address hidden>
Date: Sat Oct 20 09:14:48 2018 -0400
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>
If you're up for downloading the latest maint branch from e2fsprogs and give it a try to see if it fixes your issue, since you have a reliable repro, I would really appreciate it. Thanks!!