linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Christian Kujau <lists@nerdbynature.de>
Cc: linux-ext4@vger.kernel.org
Subject: Re: ext4_ext_check_inode: bad header/extent in inode
Date: Thu, 23 Apr 2009 07:50:50 -0500	[thread overview]
Message-ID: <49F0642A.4000704@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.01.0904191934320.6162@bogon.housecafe.de>

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

  reply	other threads:[~2009-04-23 12:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-23 12:15 ext4_ext_check_inode: bad header/extent in inode Christian Kujau
2009-04-23 12:50 ` Eric Sandeen [this message]
2009-04-23 19:04   ` Christian Kujau
2009-04-23 20:40     ` Theodore Tso
2009-04-23 22:15       ` Christian Kujau
2009-04-24  3:20         ` Theodore Tso
2009-04-24  7:09           ` Andreas Dilger
2009-04-24 11:58             ` Theodore Tso
2009-04-24 20:09               ` Andreas Dilger
2009-04-24  8:57           ` Christian Kujau
2009-04-24  9:40             ` Christian Kujau
2009-04-24 12:00               ` Theodore Tso
2009-04-24 12:36                 ` Eric Sandeen
2009-04-24 12:42                   ` Eric Sandeen
2009-04-24 20:21                   ` Christian Kujau
2009-04-24 20:34                     ` Eric Sandeen
2009-04-24 20:59                       ` Theodore Tso
2009-04-24 22:54                         ` [PATCH] ext4: Do not try to validate extents on special files Theodore Ts'o
2009-04-24 21:02                       ` ext4_ext_check_inode: bad header/extent in inode Christian Kujau
2009-04-24 21:23                         ` Eric Sandeen
2009-04-24 20:41                 ` Christian Kujau
2009-04-23 20:51     ` Andreas Dilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49F0642A.4000704@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=lists@nerdbynature.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).