From: Martin Steigerwald <Martin@lichtvoll.de>
To: xfs@oss.sgi.com
Subject: Re: LWN article: ext4 and data loss
Date: Sat, 14 Mar 2009 20:42:51 +0100 [thread overview]
Message-ID: <200903142042.51574.Martin@lichtvoll.de> (raw)
In-Reply-To: <49B92423.4020708@sandeen.net>
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 2.6.27.7. See
http://oss.sgi.com/archives/xfs/2008-12/msg00540.html
> > 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:
http://bugs.kde.org/187172
Feel free to add there. You'd need a bugzilla login tough.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-03-14 19:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 11:39 LWN article: ext4 and data loss Michael Monnerie
2009-03-12 13:09 ` Eric Sandeen
2009-03-12 14:14 ` Martin Steigerwald
2009-03-12 15:02 ` Eric Sandeen
2009-03-12 16:33 ` Greg Banks
2009-03-12 16:36 ` Eric Sandeen
2009-03-12 16:45 ` Greg Banks
2009-03-14 19:42 ` Martin Steigerwald [this message]
2009-03-14 20:02 ` Eric Sandeen
2009-03-14 20:08 ` Eric Sandeen
2009-03-14 22:03 ` Martin Steigerwald
2009-03-15 14:26 ` Peter Grandi
2009-03-14 19:43 ` Martin Steigerwald
2009-03-16 16:17 ` Michael Monnerie
2009-03-18 18:52 ` Martin Steigerwald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200903142042.51574.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.