Bug ID 1210698
Summary Superblock checksum does not match when resizing ext4 file system twice in a row
Classification openSUSE
Product openSUSE Distribution
Version Leap 15.4
Hardware x86-64
OS Other
Status NEW
Severity Major
Priority P5 - None
Component Kernel
Assignee kernel-bugs@opensuse.org
Reporter cade.robinson@nisc.coop
QA Contact qa-bugs@suse.de
Target Milestone ---
Found By ---
Blocker ---

We ran into this issue on SLES15SP5 but I can't submit bugs to them but was
able to reproduce it with opensuse 15.4.

With kernel 5.14.21-150400.24.55.3 and 5.14.21-150400.24.60.1 if I try to
extend an ext4 file system twice without an unmount or reboot I get an error
that the superblock checksum does not match:

First add of 1g:
localhost:~ # lvresize -r -L +1g /dev/vg1/testlv 
  Size of logical volume vg1/testlv changed from 8.00 GiB (2048 extents) to
9.00 GiB (2304 extents).
  Logical volume vg1/testlv successfully resized.
resize2fs 1.46.4 (18-Aug-2021)
Filesystem at /dev/mapper/vg1-testlv is mounted on /mnt; on-line resizing
required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/mapper/vg1-testlv is now 2359296 (4k) blocks long.

then add another:
localhost:~ # lvresize -r -L +1g /dev/vg1/testlv 
  Size of logical volume vg1/testlv changed from 9.00 GiB (2304 extents) to
10.00 GiB (2560 extents).
  Logical volume vg1/testlv successfully resized.
tune2fs: Superblock checksum does not match superblock while trying to open
/dev/mapper/vg1-testlv
Couldn't find valid filesystem superblock.
fsadm: Cannot parse tune2fs output.
  /usr/sbin/fsadm failed: 1

Trying to manually resize with resize2fs:
localhost:~ # resize2fs /dev/vg1/testlv 
resize2fs 1.46.4 (18-Aug-2021)
resize2fs: Superblock checksum does not match superblock while trying to open
/dev/vg1/testlv
Couldn't find valid filesystem superblock.



If I unmount and remount the FS I can resize it
Current LV size is 10g but the FS is only 9 since the add of 1G above to the LV
works but resize2fs failed.
localhost:~ # lvs /dev/vg1/testlv 
  LV     VG  Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync
Convert
  testlv vg1 -wi-ao---- 10.00g                                                  
localhost:~ # df -hPT /mnt
Filesystem             Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg1-testlv ext4  8.8G   24K  8.4G   1% /mnt

If I remount and run the resize2fs it will resize the FS fine:
localhost:~ # umount /mnt
localhost:~ # mount /dev/vg1/testlv /mnt
localhost:~ # resize2fs /dev/vg1/testlv 
resize2fs 1.46.4 (18-Aug-2021)
Filesystem at /dev/vg1/testlv is mounted on /mnt; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 2
The filesystem on /dev/vg1/testlv is now 2621440 (4k) blocks long.


Resize of unmounted FS repeatedly does work fine.

booting with kernel 5.14.21-150400.24.46.1 multiple resize2fs in a row works
fine on the same file system used in the previous test.

kernels 5.14.21-150400.24.60.1 and 5.14.21-150400.24.55.3 fail.
This is the same in SLES15SP4

I found this that helped figure out is was two resize2fs in a row:
https://www.spinics.net/lists/linux-ext4/msg86785.html

That thread mentions a possible kernel fix that may help.


You are receiving this mail because: