Re: fsync() madness
- Date: Sun, 20 Apr 2008 21:51:26 +0300
- From: Sami Liedes <sliedes@xxxxxxxxx>
- Subject: Re: fsync() madness
On Sun, Apr 20, 2008 at 07:27:54PM +0000, letto wrote: > On Sunday 20 April 2008 14:41:19 Sami Liedes wrote: > > Well, I read those threads and everyone there seems to think it's no > > major performance hit. > > What are you talking about? I've read those threads and it seems that this > behaviour was only necesarry for xfs and that it was planned to make it > detect fs at run-time and only fsync when necesarry. See this message > http://lists.kde.org/?l=kde-devel&m=119453925805510&w=2 I had missed that post. Still, no analysis of the performance hit there, and I think the attitude of "no data loss at all allowed at any power loss, implement at any cost to performance" is misguided. That's what the noasync mount option is for, and it really shouldn't be for applications to decide. I mean, of course it's not nice to get data loss when you lose power during heavy disk writes, but with current filesystems everything else might be corrupted anyway, and there's no reason to think KDE (and especially some ridiculous browser history) is somehow special and second-guess the user who uses write back cache. Sami
Attachment:
signature.asc
Description: Digital signature
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
- Follow-Ups:
- Re: fsync() madness
- From: Lubos Lunak
- Re: fsync() madness
- References:
- fsync() madness
- From: Sami Liedes
- Re: fsync() madness
- From: Oswald Buddenhagen
- Re: fsync() madness
- From: Sami Liedes
- Re: fsync() madness
- From: letto
- fsync() madness
- Prev by Date: Re: fsync() madness
- Next by Date: Re: Issues using KToolBarLabelAction
- Previous by thread: Re: fsync() madness
- Next by thread: Re: fsync() madness
- Index(es):