Re: EXT3 way too happy with write errors

[Eric Sandeen <sandeen@redhat.com>]

Simon Kirby wrote:
>> On Thu, Dec 18, 2008 at 9:49 AM, Simon Kirby <sim@netnation.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) :)