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 13:11:28 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Subject: Re: buggy EOFBLOCKS_FL handling

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.

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