linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: Kevin Shanahan <kmshanah@ucwb.org.au>
Cc: linux-ext4@vger.kernel.org
Subject: Re: ext4 bug and/or e2fsck hole
Date: Tue, 07 Apr 2009 16:51:40 -0700	[thread overview]
Message-ID: <20090407235140.GH3204@webber.adilger.int> (raw)
In-Reply-To: <20090407233955.GA4328@kulgan>

On Apr 08, 2009  09:09 +0930, Kevin Shanahan wrote:
> On Tue, Apr 07, 2009 at 04:13:24PM -0700, Andreas Dilger wrote:
> > What version of e2fsprogs is this?  It definitely appears that the
> > inode is corrupted (bad i_file_acl field), and e2fsck isn't fixing it.
> 
> Using current Debian stable release:
> 
> hermes:~# e2fsck -V
> e2fsck 1.41.3 (12-Oct-2008)
>         Using EXT2FS Library version 1.41.3, 12-Oct-2008
> 
> > Can you please dump this inode using "debugfs -c -R 'imap 383' /dev/dm-0"
> > and "dd if=/dev/dm-0 of=/tmp/bad_inode.383.bin bs=4k count=1 skip={blocknr}".
> 
> hermes:~# debugfs -c -R 'imap 383' /dev/dm-0
> debugfs 1.41.3 (12-Oct-2008)
> /dev/dm-0: catastrophic mode - not reading inode or group bitmaps
> 383: File not found by ext2_lookup 
> hermes:~# debugfs -c -R 'imap <383>' /dev/dm-0
> debugfs 1.41.3 (12-Oct-2008)
> /dev/dm-0: catastrophic mode - not reading inode or group bitmaps
> Inode 383 is part of block group 0
>         located at block 312, offset 0x0e00

000e00 845ac901 00000000 5d648154 9f6a0b23
000e10 22344c51 00000000 0001e064 00000000
000e20 c4a8c000 c591d204 9105f87d c6cf35c8
000e30 82016f23 d3a7defb af4ab245 d3123ef4
000e40 87cd5ebe fa60d394 db745504 a6f3a34d
000e50 6a5985d4 ac8cebf1 a605db29 548c8e6e
000e60 f665b0c8 e58c1934 00000000 00000000
000e70 00000000 5db50000 b6ae09f5 6bc9469f
000e80 9c950004 5b8f755b e31b8760 e49bfe80
000e90 215242b0 f708f501 ab1d808d 4143a941
000ea0 83ff4c83 36858a3e db376e67 c87ee64e
000eb0 c10e0487 8dc325a1 4e7327aa 71a6c841
000ec0 4014140b d18816c7 87898dba b986e891
000ed0 2dab53ed 8fef04ef f33deb1c 47010862
000ee0 c551c546 2c463176 0b0c554a 76af3850
000ef0 271cc4fa 457664de 79b808d5 4456415a

This inode looks like total garbage, unlike the ones immediately before
and after it in the same block.  Why e2fsck doesn't complain about this
inode is a bit of a mystery.


Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.


  reply	other threads:[~2009-04-07 23:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-07 20:48 ext4 bug and/or e2fsck hole Kevin Shanahan
2009-04-07 23:13 ` Andreas Dilger
2009-04-07 23:39   ` Kevin Shanahan
2009-04-07 23:51     ` Andreas Dilger [this message]
2009-04-07 23:58     ` Andreas Dilger
2009-04-08  4:43       ` Kevin Shanahan

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=20090407235140.GH3204@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=kmshanah@ucwb.org.au \
    --cc=linux-ext4@vger.kernel.org \
    /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).