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

Message-ID: <alpine.DEB.2.01.0904191934320.6162@bogon.housecafe.de>
Date:	Thu, 23 Apr 2009 05:15:40 -0700 (PDT)
From:	Christian Kujau <lists@...dbynature.de>
To:	linux-ext4@...r.kernel.org
Subject: ext4_ext_check_inode: bad header/extent in inode

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.

Details about the process (mkfs, fsck, etc.), a .config and kernel logs 
are here: http://nerdbynature.de/bits/2.6.30-rc2/

Thanks,
Christian.
-- 
Only Bruce Schneier is allowed to wear the "I read the NSA's e-mail" t-shirt.
--
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