linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: linux-ext4@vger.kernel.org
Subject: Re: buggy EOFBLOCKS_FL handling
Date: Thu, 19 Aug 2010 10:44:32 -0400	[thread overview]
Message-ID: <20100819144432.GA23345@thunk.org> (raw)
In-Reply-To: <FB932B24-52F7-4C97-9BF6-58A78DFA5FBF@dilger.ca>

On Wed, Aug 18, 2010 at 11:13:00PM -0600, Andreas Dilger wrote:
> On 2010-08-18, at 21:01, Theodore Ts'o wrote:
> > It looks like how we handle the EOFBLOCKS_FL flag is buggy.  This means
> > that when we fallocate a file to have 128k using the KEEP_SIZE flag, and
> > then write exactly 128k, the EOFBLOCKS_FL isn't getting cleared
> > correctly.
> > 
> > This is bad, because e2fsck will then complain about that inode.  If you
> > have a large number of inodes that are written with fallocate using
> > KEEP_SIZE, and then fill them up to their expected size, e2fsck will
> > potentially complain about a _huge_ number of inodes.
> 
> Probably e2fsck also shouldn't complain if EOFBLOCKS_FL is set, but
> the i_size is within the range implied by i_blocks.

My current thinking is to have an EOFBLOCKS_relaxed mode setting in
/etc/e2fsck.conf which controls whether we test for this case or not.
Technically it *is* an error, but if there are file systems with a
large number of files in this state, running e2fsck could take a
***very*** long time (potentially, hours longer than would otherwise
be expected).  Hopefully once the bug fix gets pushed out, eventually
we'll be able to turn this feature off.  (Where eventually might be a
year or two, given that it's probably too late to get this fixed in
RHEL 6.  :-( )

	   	    	    	      - Ted


  reply	other threads:[~2010-08-19 14:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-19  3:01 buggy EOFBLOCKS_FL handling Theodore Ts'o
2010-08-19  3:04 ` [PATCH, RFC] ext4: Fix " Theodore Ts'o
2010-08-21 21:07   ` [PATCH -v2] " Theodore Ts'o
2010-08-19  5:13 ` buggy " Andreas Dilger
2010-08-19 14:44   ` Ted Ts'o [this message]
2010-08-19 17:03     ` Eric Sandeen
2010-08-19 17:11       ` Ted Ts'o
2010-08-19 18:33         ` Andreas Dilger
2010-08-21 20:11 ` Updated test case Ted Ts'o
2010-08-22  0:40   ` Eric Sandeen
2010-08-22 11:42     ` Ted Ts'o
2010-08-22 15:35       ` Eric Sandeen
2010-08-23 18:05       ` 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=20100819144432.GA23345@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --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).