Resized (downsized) an offline ext4 filesystem on LVM. Before resizing, I confirmed filesystem was clean with e2fsck. After resizing, several warnings/errors were found. Tried first with version 1.44.1 from Ubuntu 18.04.1 LTS. Then I compiled the 1.44.4 source, but the error was still present. Using ESXi 6.7 and starts with a fresh copy of the filesystem before each run.
root@vedlikehold:~# e2fsck -f /dev/skole-vg/root
e2fsck 1.44.4 (18-Aug-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/skole-vg/root: 139206/8331264 files (0.2% non-contiguous), 3274416/33294336 blocks
root@vedlikehold:~# resize2fs -P /dev/skole-vg/root
resize2fs 1.44.4 (18-Aug-2018)
Estimated minimum size of the filesystem: 3337578
root@vedlikehold:~# lvresize --resizefs -l 11776 /dev/skole-vg/root
fsck from util-linux 2.31.1
/dev/mapper/skole--vg-root: clean, 139206/8331264 files, 3274416/33294336 blocks
resize2fs 1.44.4 (18-Aug-2018)
Resizing the filesystem on /dev/mapper/skole--vg-root to 12058624 (4k) blocks.
The filesystem on /dev/mapper/skole--vg-root is now 12058624 (4k) blocks long.
Size of logical volume skole-vg/root changed from <127.01 GiB (32514 extents) to 46.00 GiB (11776 extents).
Logical volume skole-vg/root successfully resized.
root@vedlikehold:~# e2fsck -f /dev/skole-vg/root
e2fsck 1.44.4 (18-Aug-2018)
Pass 1: Checking inodes, blocks, and sizes
Inode 8 extent tree (at level 1) could be narrower. Fix<y>? yes
Inode 44075 extent block passes checks, but checksum does not match extent
(logical block 10240, physical block 421888, len 8691)
Fix<y>? yes
Inode 44083 extent block passes checks, but checksum does not match extent
(logical block 51200, physical block 3414016, len 10293)
Fix<y>? yes
Inode 44087 extent block passes checks, but checksum does not match extent
(logical block 34816, physical block 3444736, len 574)
Fix<y>? yes
Inode 44091 extent block passes checks, but checksum does not match extent
(logical block 28672, physical block 4087808, len 7804)
Fix<y>? yes
Inode 44093 extent block passes checks, but checksum does not match extent
(logical block 26624, physical block 4030464, len 351)
Fix<y>? yes
Inode 44106 extent block passes checks, but checksum does not match extent
(logical block 49152, physical block 1308672, len 8370)
Fix<y>? yes
Inode 44112 extent block passes checks, but checksum does not match extent
(logical block 69632, physical block 1607680, len 16969)
Fix<y>? yes
Inode 44116 extent block passes checks, but checksum does not match extent
(logical block 2848, physical block 7861156, len 178)
Fix<y>? yes
Inode 44117 extent block passes checks, but checksum does not match extent
(logical block 1592, physical block 7862368, len 98)
Fix<y>? yes
Inode 44119 extent block passes checks, but checksum does not match extent
(logical block 2150, physical block 15663, len 134)
Fix<y>? yes
Inode 44120 extent block passes checks, but checksum does not match extent
(logical block 24934, physical block 5329460, len 1014)
Fix<y>? yes
Inode 44122 extent block passes checks, but checksum does not match extent
(logical block 734, physical block 3257320, len 44)
Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/skole-vg/root: 139206/3014656 files (0.2% non-contiguous), 2938632/12058624 blocks
root@vedlikehold:~#
This looks like a dup of https:/
and is fixed by:
commit 4b3038134baf81c
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-
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!!