linux-ext4 - Re: corrupt filesystem, superblock/journal

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 23 May 2018 13:37:32 +0200
From:   Jan Kara <jack@...e.cz>
To:     Jaco Kroon <jaco@....co.za>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>,
        Pieter Kruger <pieter@....co.za>
Subject: Re: corrupt filesystem, superblock/journal - fsck

Hi,

On Mon 21-05-18 14:21:33, Jaco Kroon wrote:
> We had a host starting to fail processing on an ext4 filesystem directly
> after extend from 60.5TB to 64TB (lvresize -L64T /dev/lvm/home,
> resize2fs /dev/lvm/home).
> 
> We rebooted, and now the filesystem will mount but the problem
> persists.  We've now umounted the filesystem, and fsck complains as follows:
> 
> crowsnest ~ # fsck.ext4 -f /dev/lvm/home
> e2fsck 1.43.6 (29-Aug-2017)
> Superblock has an invalid journal (inode 8).
> Clear<y>? yes
> *** journal has been deleted ***
> 
> Corruption found in superblock.  (inodes_count = 0).
> 
> The superblock could not be read or does not describe a valid ext2/ext3/ext4
> filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt, and you might try running e2fsck with an alternate superblock:
>     e2fsck -b 8193 <device>
>  or
>     e2fsck -b 32768 <device>
> 
> Corruption found in superblock.  (first_ino = 11).
> 
> The superblock could not be read or does not describe a valid ext2/ext3/ext4
> filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt, and you might try running e2fsck with an alternate superblock:
>     e2fsck -b 8193 <device>
>  or
>     e2fsck -b 32768 <device>
> 
> Inode count in superblock is 0, should be 4294967295.
> Fix<y>? yes
> 
> /dev/lvm/home: ***** FILE SYSTEM WAS MODIFIED *****

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.

								Honza

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR