linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Adam Huffman <adam.huffman@gmail.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: Filesystem corruption on Fedora 17
Date: Wed, 28 Nov 2012 16:15:55 -0500	[thread overview]
Message-ID: <20121128211555.GA30650@thunk.org> (raw)
In-Reply-To: <CAP5prOhXZS+x4xAEOYcTquVFz9rtTVeyhK_x2qajKGoKxfw5vA@mail.gmail.com>

On Wed, Nov 28, 2012 at 06:16:40PM +0000, Adam Huffman wrote:
> > Can you send me a copy of the output of:
> >
> > debugfs -w /dev/XXXX
> > debugfs: stat <4122234>
> 
> debugfs:  stat 4122234
> 4122234: File not found by ext2_lookup

You need the angle brackets.  A number in angle brackets is
interpreted as an inode number.  Without the angle brackets then
debugfs tries to do a lookup in the debugfs's current working directory.

> As I said in the other reply, I was able to mount the image in the
> end.  Perhaps one of those fsck invocations made a difference, even
> though the same error appeared each time?

Well, if e2fsck doesn't fix a corruption in a single pass, barring
hardware failures, it's a bug in e2fsck by definition (at least in my
book).  If the same error is appearing each time, that doesn't mean
that the file system can't be mounted.  Unless you actually try to
reference the corrupted inode in question, you might never know about
the corruption.

You can use the ncheck command in debugfs if you want to map an inode
number to a pathname.  ("ncheck 4122234" --- no angle brackets since
ncheck only takes inode numbers and maps them to pathnames, just as
icheck takes block numbers and maps them to inode numbers).

       	     	   	       	    	 - Ted

      reply	other threads:[~2012-11-28 21:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 13:31 Filesystem corruption on Fedora 17 Adam Huffman
2012-11-27 16:47 ` Theodore Ts'o
2012-11-27 16:59   ` Adam Huffman
2012-11-27 17:31     ` Theodore Ts'o
2012-11-27 18:40       ` Adam Huffman
2012-11-28 18:16       ` Adam Huffman
2012-11-28 21:15         ` Theodore Ts'o [this message]

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=20121128211555.GA30650@thunk.org \
    --to=tytso@mit.edu \
    --cc=adam.huffman@gmail.com \
    --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).