linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: linux-ext4@vger.kernel.org
Subject: Re: e2fsck aborts when invalid indirect block is encountered
Date: Thu, 1 Sep 2011 13:00:39 -0400	[thread overview]
Message-ID: <20110901170039.GA4110@thunk.org> (raw)
In-Reply-To: <20110901063410.GA8313@notebook.chenhuan>

On Thu, Sep 01, 2011 at 02:34:10PM +0800, Chen Huan wrote:
> Hi, All.
> 
> During a recent read-only checking of an corrupted ext3 file system,
> I found a strange behaviour of e2fsck: when an inode has an invalid
> indirect block number, e2fsck aborts with the following message:
> 
>     e2fsck 1.39 (29-May-2006)
>     Pass 1: Checking inodes, blocks, and sizes
>     Inode 12 has illegal block(s).  Clear? no
> 
>     Illegal block #-1 (4294967295) in inode 12.  IGNORED.
>     Error while iterating over blocks in inode 12: Illegal indirect block found
>     e2fsck: aborted

> My question is: Is this behaviour a bug or intended?

This is deliberate.  There are two reasons for this:

(1) e2fsck -n is currently defined as being equivalent to (a) opening
the file system read-only, and (b) answering 'no' to all questions
asked by e2fsck.

(2) In the case where you *aren't* doing an e2fsck -n, there are
certain situations where not correcting an error means (a) that its
dangerous to try to fix anything afterwards, and that (b) many of the
diagnostics issued by e2fsck can not be relied upon.

We could change things so that e2fsck doesn't abort in the case where
-n is specified, which would avoid the problem 2a, but it breaks the
definition of 1b.  It also doesn't solve the problem listed in 2b.
Still, if it's really annoying it's something I could consider
changing.  Let me sleep on it.

	      	      	   	   - Ted

      parent reply	other threads:[~2011-09-01 17:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-01  6:34 e2fsck aborts when invalid indirect block is encountered Chen Huan
2011-09-01  8:17 ` Andreas Dilger
2011-09-01  8:52   ` Chen Huan
2011-09-01 17:00 ` Ted 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=20110901170039.GA4110@thunk.org \
    --to=tytso@mit.edu \
    --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).