linux-ext4 - Re: fsck.ext4 taking a very long time because of "should not have EOFBLOCKS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111019185344.GA4284@thunk.org>
Date:	Wed, 19 Oct 2011 14:53:44 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Johannes Segitz <johannes.segitz@...il.com>
Cc:	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 06:02:12PM +0200, Johannes Segitz wrote:
> Hello,
> 
> yesterday i was forced to start a fsck of an ext4 filesystem (4 TB on
> a encrypted raid5 array). After a while a got a lot
> of those messages:
> Inode 23565579 should not have EOFBLOCKS_FL set (size 0, lblk -1)
> 
> After some googling i found this thread
> http://kerneltrap.org/mailarchive/linux-ext4/2010/8/19/6885408/thread#mid-6885408

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...

> Since it's something that can be taken care of by using "-p" i started
> it yesterday and was kind of surprised
> to discover it running happily today with no sign of stopping. I piped
> the output to /dev/null since the printing
> of the messages alone caused quite a bit of load so i don't know at
> which inode fsck currently is.
> 
> Is there a way to speed things up? If i understand the thread
> correctly those errors should self correct over time
> and i don't want to wait anymore. Can i do any harm by killing fsck
> and start it again without the pipe to see
> at which inode it currently is?

What version of e2fsprogs are you using?  Given that you're using an
old version of the kernel there's a good chance you're using a old
version of e2fsprogs.  Are you willing to upgrade to a newer kernel
and e2fsprogs?  If so, the following procedure documented in the
following commit, which is included in e2fsprogs 1.41.13 or newer,
should help you out (see below).

						- Ted

commit 75990388365c5688dbade9c33a3394e40f757526
Author: Theodore Ts'o <tytso@....edu>
Date:   Mon Dec 6 10:10:33 2010 -0500

    e2fsck: Add the ability to force a problem to not be fixed
    
    The boolean options "force_no" in the problems stanza of e2fsck.conf
    allows a particular problem code be treated as if the user will answer
    "no" to the question of whether a particular problem should be fixed
    --- even if e2fsck is run with the -y option.
    
    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.  Enough, in fact, the e2fsck runs were taking too
    long.  (There was such a bug in the kernel, which was fixed by commit
    58590b06d in 2.6.36).
    
    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
    }
    
    Signed-off-by: "Theodore Ts'o" <tytso@....edu>

--
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