[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFj9jjzE_hW9sx3qAWrF+L9rufLL9rVZe_17Tqnk0WLgEiw_=Q@mail.gmail.com>
Date: Thu, 20 Oct 2011 12:58:52 +0200
From: Johannes Segitz <johannes.segitz@...il.com>
To: linux-ext4@...r.kernel.org
Subject: Re: fsck.ext4 taking a very long time because of "should not have
EOFBLOCKS_FL set"
On Wed, Oct 19, 2011 at 20:53, Ted Ts'o <tytso@....edu> wrote:
> On Wed, Oct 19, 2011 at 06:02:12PM +0200, Johannes Segitz wrote:
> What kernel version are you using, and can you upgrade to one that has
> this bug fixed? This is a problem which was fixed over a year ago...
2.6.38-11-generic #50-Ubuntu SMP
I was running 3.0.4 until a few days ago.
I didn't fsck the filesystem for quite a while and the files on this
volume don't get
rewritten so it doesn't fix itself so i think it's just something that
was caused some
time ago and still persists
> What version of e2fsprogs are you using?
1.41.14-1ubuntu3 which seems to be the newest version
> As an example use case, suppose a distribution had widely deployed a
> version of the kernel where under some circumstances, the EOFBLOCKS_FL
> flag would be left set even though it should not be left set, and a
> customer had a workload which exercised the fencepost error all the
> time, resulting in many large number of inodes that had EOFBLOCKS_FL
> set erroneously.
yeah "suppose" ;)
> Leaving EOFBLOCKS_FL set when it should not be isn't a huge deal, and
> is certainly than having high availability timeout alerts going off
> left and right. So in this case, the best fix might be to put the
> following in /etc/e2fsck.conf:
>
> [problems]
> 0x010060 = { # PR_1_EOFBLOCKS_FL_SET
> force_no = true
> no_ok = true
> no_nomsg = true
> }
That was pretty much what i was looking for, thank you. I'll kill fsck
tonight if it's still
running and run it again with those settings.
Thank you for your help
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists