[Top] [All Lists]

Re: LWN article: ext4 and data loss

To: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Subject: Re: LWN article: ext4 and data loss
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 12 Mar 2009 10:02:59 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <200903121514.12732.Martin@xxxxxxxxxxxx>
References: <200903121239.35442@xxxxxx> <49B9097C.1070003@xxxxxxxxxxx> (sfid-20090312_151043_496061_D19DDB11) <200903121514.12732.Martin@xxxxxxxxxxxx>
User-agent: Thunderbird (X11/20090105)
Martin Steigerwald wrote:
> Am Donnerstag 12 März 2009 schrieb Eric Sandeen:
>> Michael Monnerie wrote:
>>> http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/
>>> Very good, maybe similar patches for XFS would help?
>>> IANA Coder, but could be a hint.
>>> mfg zmi
>> ext4 is taking its hints from XFS in this regard, not the other way
>> around.  XFS dealt with this long ago.
> Hmmm, I remember having had similar issues with XFS not to long ago, where 

depends on what you mean by not too long ago, I think.  Yes, kde had
this issue on xfs too, and xfs gave up on teaching apps to fsync, and
implemented the same sorts of things ext4 has done (or will do) to
mitigate this quite some time ago.

> at least some KDE configuration were lost or truncated. It seems 
> applications will have to get rid of behavioral assumptions regation 
> filesystem and use safe writing via fsync and whatever else for 
> configuration and other important files.

It's simple.  Want your data safe on disk?  fsync.  There's not a lot
more to it than that.  (and if fsync hurts perf too much, re-think how
you are storing your data)

Filesystems can hack around some heuristics to try to make unsafe apps
safer, but in the end, it's the app's job to make sure a buffered write
hits permanent storage when it matters.


> I am thinking about a bug report for KDE at least.

<Prev in Thread] Current Thread [Next in Thread>