From: Eric Sandeen <sandeen@redhat.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>, linux-ext4@vger.kernel.org
Subject: Re: buggy EOFBLOCKS_FL handling
Date: Thu, 19 Aug 2010 12:03:17 -0500 [thread overview]
Message-ID: <4C6D63D5.8030600@redhat.com> (raw)
In-Reply-To: <20100819144432.GA23345@thunk.org>
Ted Ts'o wrote:
> 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. :-( )
Oh it can get fixed during rhel6's lifetime, certainly. :)
Regarding a conf file setting, I'd really rather not have another knob
that is non-obvious to the user.
Maybe e2fsck could tally these and after I dunno, 10 or 20 or so, ask
whether it should keep flagging them or just go into "yes" mode for
the rest of the inodes with that problem?
-Eric
next prev parent reply other threads:[~2010-08-19 17:03 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
2010-08-19 17:03 ` Eric Sandeen [this message]
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=4C6D63D5.8030600@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--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).