linux-ext4 - Re: ext4_ext_check_inode: bad header/extent in inode

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Apr 2009 07:50:50 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Christian Kujau <lists@...dbynature.de>
CC:	linux-ext4@...r.kernel.org
Subject: Re: ext4_ext_check_inode: bad header/extent in inode

Christian Kujau wrote:
> Hi there,
> 
> let's say "something" happened to this ext4 partition - OK, I created a 
> ZFS pool on a freshly created (unmounted) ext4 partition (for testing 
> purposes) and this might have wiped some ext4 information off the 
> partition. But I was able to mount the partition again and it looked
> like as if all data was in place. 
> 
> However, a fsck later on revealed and fixed quite a few errors. Now the 
> filesystem can still be mounted, but some files cannot be read:
> 
> ------------------
> # mount -t ext4 /dev/md0 /mnt/md0
> # ls -la /mnt/md0 /mnt/md0/lost+found
> /mnt/md0:
> total 28
> drwxr-xr-x  4 root  root   4096 Apr 23 13:43 .
> drwxr-xr-x  4 root  root   4096 Apr  2 13:39 ..
> drwxr-xr-x 23 dummy users  4096 Apr 18 21:06 linux-2.6-git
> drwx------  3 root  root  16384 Apr 23 13:43 lost+found
> ls: cannot access /mnt/md0/lost+found/#12042: Input/output error
> ls: cannot access /mnt/md0/lost+found/#12207: Input/output error
> ls: cannot access /mnt/md0/lost+found/#12249: Input/output error
> -------------------
> 
> 
> I realize that "creating a filesystem on an ext4 partition" may indeed 
> harm ext4 information and I don't expect fsck to get everything fixed - 
> but then I think: in the real world this "destruction" could be caused 
> by bad memory/cables or just a disk controller gone mad - so yes, some 
> ext4 information may have been lost, but:
> 
> Shouldn't fsck (1.41.3) complain more, when there are errors left
> on the filesystem? Even if the errors cannot be fixed, I'd have 
> expected fsck to tell me about that. But fsck exits clean on the 2nd run, 
> but there are still a few files unaccessible.

Yep, probably so; based on:

[400026.511081] EXT4-fs error (device md0): ext4_ext_check_inode: bad
header/extent in inode #12120: invalid magic - magic 702, entries 30990,
max 5120(0), depth 55352(55352)
[400026.519200] EXT4-fs error (device md0): ext4_ext_check_inode: bad
header/extent in inode #12272: invalid magic - magic 1c2b, entries 6928,
max 14(0), depth 4116(4116)

I'd have expected fsck to find that, I think.  I'd first suggest using
1.41.4 or 1.41.5 (probably released very soon) and see if that catches
it (I don't remember offhand if there is a relevant change since 1.41.3
but the check should be easy...)

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html