[Top] [All Lists]

Re: LWN article: ext4 and data loss

To: xfs@xxxxxxxxxxx
Subject: Re: LWN article: ext4 and data loss
From: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Date: Sat, 14 Mar 2009 20:42:51 +0100
In-reply-to: <49B92423.4020708@xxxxxxxxxxx>
References: <200903121239.35442@xxxxxx> <200903121514.12732.Martin@xxxxxxxxxxxx> <49B92423.4020708@xxxxxxxxxxx> (sfid-20090312_171308_416656_6FF6859A)
User-agent: KMail/1.9.9
Am Donnerstag 12 März 2009 schrieb Eric Sandeen:
> 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.

Well 2.6.28 and See


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

Hmmm, okay. So here is:


Feel free to add there. You'd need a bugzilla login tough.

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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