Hi Jan, On 23/05/2018 13:37, Jan Kara wrote: > Hi, > OK, so the Inode count is obviously wrong and the remaining errors are due > to that. Apparently the resize process has overflown the inode count to 0 > (which is not that surprising since the number of inodes in your filesystem > would be 1<<32) - that needs fixing but let's first get your fs up and > running. I'm actually surprised that e2fsck did anything with the > filesystem because for me both 1.44.2 and 1.42.11 versions just exit after > printing the error about the corrupted superblock. Anyway what *could* fix > your problem is: > > debugfs -w -R 'ssv inodes_count 4294967295' /dev/lvm/home > > and then check with dumpe2fs that inode count indeed got fixed. Hope it > helps. I started to investigate the superblocks as well. Using hexdump and dd ... scary. Came to the same conclusion, tried to fix it by replacing it in the superblock using dd but that caused other issues so reverted it back to all zero. Also tried with debugfs but could not figure out how to use it so the above helped a lot thank you so much! Unfortunately it doesn't help: crowsnest ~ # dumpe2fs /dev/lvm/home dumpe2fs 1.44.2 (14-May-2018) dumpe2fs: The ext2 superblock is corrupt while trying to open /dev/lvm/home Couldn't find valid filesystem superblock. fsck and debugfs also now fails, managed to revert that using: crowsnest ~ # echo -ne "\x00\x00\x00\x00" | dd of=/dev/lvm/home bs=4 count=1 seek=256 conv=notrunc 1+0 records in 1+0 records out 4 bytes copied, 0.0213468 s, 0.2 kB/s And now we're back to where we started. So I'm contemplating if 2^32-1 is not perhaps an explicitly invalid value, but I've tried 2^32-2 (4294967294) as well, same result. Busy trying to check the e2fsck source files. There are quite a few things that can go wrong during ext2fs_open2() and it's unclear what exactly is going wrong here. Looks like I may have to modify the code to get the error value ... Since it happened during (directly after?) resize2fs we are actually thinking potential kernel bug. Original FS size was 61TB and upsized to exactly 64TB. In terms of 4096KB blocks that's EXACTLY 2^34 blocks, so I also aim to look at the kernel sources there, but as you say - first we need to get the filesystem up. Kind Regards, Jaco
