linux-ext4 - Re: *** SPAM *** Re: e2fsck fails with unable to set superblock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 30 Jan 2020 12:55:52 +0200
From:   Jaco Kroon <jaco@....co.za>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: *** SPAM *** Re: e2fsck fails with unable to set superblock

Hi,

On 2020/01/29 22:00, Andreas Dilger wrote:
> On Jan 28, 2020, at 9:35 PM, Jaco Kroon <jaco@....co.za> 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