linux-ext4 - Re: buggy 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]

Date:	Thu, 19 Aug 2010 12:33:36 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Ted Ts'o <tytso@....edu>
Cc:	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: buggy EOFBLOCKS_FL handling

On 2010-08-19, at 11:11, Ted Ts'o wrote:
> On Thu, Aug 19, 2010 at 12:03:17PM -0500, Eric Sandeen wrote:
>> 
>> 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?
> 
> Maybe.  I'd need to do some testing to see what percentage of the
> "takes hours longer" is caused by needing to fix truly vast numbers of
> inodes, versus the fact that writing the e2fsck log file was taking a
> huge amount of time.  I'm not sure, asking the user, "I've tried
> fixing 100 of these inodes, and it looks like there are runs more,
> want to skip checking for the rest" is all that great (i.e., a "go
> into automatic 'no' mode for this question").
> 
> The other possibility is that I'd make it configurable by e2fsck.conf,
> but change the default to be "ignore this fs error", and then 2-3
> years later, change the default to "check for this fs error", without
> actually requiring most users to have a knob in their e2fsck.conf
> file.

To me this falls into the class of "silently fix our mistake" kind of problem, similar to what we did in the Lustre e2fsprogs with the extent "_hi" field not being initialized in early versions of the extent patch.

If the slowdown is due to actually updating thousands of such inodes (vs. just printing the error on the screen) you could cap the number of inodes fixed for this problem at some limit, and then every time a full e2fsck is run it would fix a bunch more.

Presumably an updated kernel and regular filesystem usage would also tend to clean up this flag if old files are deleted and new ones created, but it is good to have e2fsck do it also, for files that are not modified for a long time.

Cheers, Andreas

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