fsync() madness

[Lubos Lunak]

On Monday 21 of April 2008, Esben Mose Hansen wrote:
> On Monday 21 April 2008 14:11:40 Lubos Lunak wrote:
> > On Sunday 20 of April 2008, Sami Liedes wrote:
> > > 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.
> >
> >  Tell that to XFS developers and their users. Anyway, where's your patch?
>
> I discussed this with a friend (who liked XFS because it could online grow
> >:) ) and it seems that the worst part of XFS behaviour in this regard was
> fixed in 2.6.22 --- the bit where any dirty file was zeroed just to be
> sure(!). So maybe we don't have to sync() quite so much now.  He has tested
> it a lot of times by installing a bios that crashed linux all the time, and
> it seems to work much better now :)

 Any objections to disabling the syncing by default (KDE3 it seems, KDE4 lost 
the syncing as a part of switching to QTemporaryFile)? I'd still leave at 
least an env.variable to enable it again, just to be sure.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz