From: Andreas Dilger <adilger@sun.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Kevin Shanahan <kmshanah@ucwb.org.au>,
Eric Sandeen <sandeen@redhat.com>,
linux-ext4@vger.kernel.org
Subject: Re: Possible ext4 corruption - ACL related?
Date: Tue, 10 Mar 2009 18:38:45 -0600 [thread overview]
Message-ID: <20090311003845.GB3199@webber.adilger.int> (raw)
In-Reply-To: <20090310224810.GA15229@mit.edu>
On Mar 10, 2009 18:48 -0400, Theodore Ts'o wrote:
> On Wed, Mar 11, 2009 at 07:44:51AM +1030, Kevin Shanahan wrote:
> > Thanks Ted. Just so I know what I'm doing if/when this comes up again, I
> > guess the process would be:
> >
> > - debugfs /dev/some-filesystem
> > - debugfs: stat "some/problem/file"
> > - get the inode number from the output above (867 in this case)
> > - debugfs dump 867 inode867.bin
>
> Actually, it's a bit more complicated than that. I should really add
> a hook to debugfs to automate this, but... to find the block to grab,
> you do this.
[many complex steps deleted]
> So now we know that the block containing inode 867 is 65+54 = 119
Or you can use imap (which Ted probably wrote in the first place. :-)
debugfs: imap some/problem/file
Inode 867 is part of block group 0
located at block 119, offset 0x0180
> Now to dump that block, we do:
>
> dd if=/dev/fs-device of=block-119.dump bs=4k skip=119 count=1
This part is the same.
> > Or perhaps running e2fsck -n first to see which inodes really look
> > corrupted and get the numbers that way.
>
> Yep. In general, when you get corruption like this, the bad inodes
> comes in chunks of 16 (if you are using 256 byte inodes) or 32 (if you
> are using 128 byte inodes).
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2009-03-11 0:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-09 23:43 Possible ext4 corruption - ACL related? Kevin Shanahan
[not found] ` <49B5D71D.1030802@redhat.com>
[not found] ` <1236655451.30280.29.camel@kulgan.wumi.org.au>
2009-03-10 4:35 ` Eric Sandeen
2009-03-10 5:02 ` Kevin Shanahan
2009-03-10 7:09 ` Andreas Dilger
2009-03-10 14:46 ` Theodore Tso
2009-03-10 21:14 ` Kevin Shanahan
2009-03-10 22:48 ` Theodore Tso
2009-03-11 0:38 ` Andreas Dilger [this message]
2009-03-11 0:47 ` Theodore Tso
2009-03-11 1:43 ` Kevin Shanahan
2009-03-11 1:48 ` Kevin Shanahan
2009-03-11 4:50 ` Theodore Tso
2009-03-11 5:27 ` Kevin Shanahan
2009-03-11 6:18 ` Andreas Dilger
2009-03-11 13:25 ` Theodore Tso
2009-03-11 18:07 ` Kevin Shanahan
2009-03-13 0:55 ` Theodore Tso
2009-03-13 14:28 ` Kevin Shanahan
2009-03-11 11:37 ` Manish Katiyar
2009-03-10 12:15 ` Kevin Shanahan
2009-03-10 20:44 ` Andreas Dilger
2009-03-10 20:59 ` 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=20090311003845.GB3199@webber.adilger.int \
--to=adilger@sun.com \
--cc=kmshanah@ucwb.org.au \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/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).