Hi, On 2020/01/29 22:00, Andreas Dilger wrote: > On Jan 28, 2020, at 9:35 PM, Jaco Kroon <jaco@xxxxxxxxx> wrote: >> Hi, >> >> Inode 181716301 block 33554947 conflicts with critical metadata, >> skipping block checks. >> Inode 181716301 block 524296 conflicts with critical metadata, skipping >> block checks. >> Inode 181716301 block 2 conflicts with critical metadata, skipping block >> checks. >> Inode 181716301 block 294 conflicts with critical metadata, skipping >> block checks. >> Inode 181716301 block 1247805839 conflicts with critical metadata, >> skipping block checks. >> Inode 181716301 block 288 conflicts with critical metadata, skipping >> block checks. >> Inode 181716301 block 103285040 conflicts with critical metadata, >> skipping block checks. >> Inode 181716301 block 872415232 conflicts with critical metadata, >> skipping block checks. >> Inode 181716301 block 2560 conflicts with critical metadata, skipping >> block checks. >> Inode 181716301 block 479199248 conflicts with critical metadata, >> skipping block checks. >> Inode 181716301 block 1006632963 conflicts with critical metadata, >> skipping block checks. > This inode is probably just random garbage. Erase that inode with: > > debugfs -w -R "clri <181716301>" /dev/sdX > > There may be multiple such inodes with nearby numbers in the likely > case that a whole block is corrupted. There has been some discussion > about the best way to handle such corruption of a whole inode table > block, but nothing has been implemented in e2fsck yet. crowsnest ~ # debugfs -w -R "clri <181716301>" /dev/lvm/home debugfs 1.45.4 (23-Sep-2019) /dev/lvm/home: Block bitmap checksum does not match bitmap while reading allocation bitmaps clri: Filesystem not open -n sorts that out. There were a few other inodes too, wiped them too, restarted fsck now. > >> So the critical block stuff I'm guessing can be expected since a bunch >> of those tree structures probably got zeroed too. >> >> It got killed because it ran out of RAM (OOM killer), 32GB physical + >> 16GB swap. I've extended swap to 512GB now and restarted. It's >> probably overkill (I hope). >> >> Any ideas on what might be consuming the RAM like this? Unfortunately >> my scroll-back doesn't go back far enough to see what other inodes if >> any are also affected. I've restarted with 2>&1 | tee /var/tmp/fsck.txt >> now. >> >> Happy to go hunting to look for possible optimization ideas here ... >> >> Another idea is to use debugfs to mark inode 181716301 as deleted, but >> I'm not sure that's safe at this stage? > Marking it "deleted" isn't really the right thing, since (AFAIR) that > will just update the inode bitmap and possibly set the "i_dtime" field > in the inode. The "clri" command will zero out the inode, which erases > all of the bad block allocation references for that inode. This is no > "loss" since the inode is already garbage. Agreed and makes perfect sense. Kind Regards, Jaco
