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@xxxxxxx> 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@xxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
