linux-ext4 - Re: EXT3 way too happy with write errors

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 02 Jan 2009 20:45:29 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Simon Kirby <sim@...nation.com>
CC:	Michael Rubin <mrubin@...gle.com>, Jan Kara <jack@...e.cz>,
	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
	Mike Snitzer <snitzer@...il.com>,
	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org
Subject: Re: EXT3 way too happy with write errors

Simon Kirby wrote:
>> On Thu, Dec 18, 2008 at 9:49 AM, Simon Kirby <sim@...nation.com> wrote:
>>> Not aborting on data write error: User loses data.  File system gets very
>>> confused.

A *data* write error should not confuse the *filesystem* - it'll just be
a corrupt file (assuming it was just an EIO / write failure and not some
misdirected IO).

>>> What am I missing?
>> I can think of certain situations when companies may care about
>> getting most of the data to disk and clean it up later.
>> Datacenters may be replicating the data to many spindles and may
>> sometimes care about throughput as much as possible. So lossy data
>> could be preferred to complete data.
>>
>> Not saying this is always preferred but I can see a use case.
> 
> Ok, fine, in this case they might know what they are doing.  Still, this
> is not reason enough to default the case in point... ?
> 
> :)

So one thing I have not seen clearly stated:

When you got the initial write error that bothers you; was that for data
 or metadata?

For a metadata write it should certainly not be ignored (other than for
crazy people who run with errors=ignore) because this implies that the
filesystem is no longer consistent.

But for a data write error there is some grey area.  If your application
cares about data integrity then it'd be doing direct IO or syncing data
and checking for errors; if it's doing buffered writes and carrying on
blindly assuming that everything is sweetness and light, well, that's
the application's choice.  But assuming the entire filesystem should
implode on one file's data write failure is probably not the best plan.

FWIW, Part of the reason for the defaults as they are, IIRC, is to keep
the current/historical behavior, but with an option to be more strict
for those who wish it.  As you do.  :)

-Eric (coming off a long vacation and hoping he's remembering this all
correctly) :)
--
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