From: "Alexander Larsson", Date: 12/08/2009 03:55, Wrote:
> On Tue, 2009-08-11 at 17:55 +0200, Xavier Bestel wrote:
>> On Tue, 2009-08-11 at 16:35 +0100, jcup...@gmail.com wrote:
>>> Oh ahem, I guess I'm thinking of sync() rather than fsync(). Though in
>>> this case one sync() at the end of the delete would certainly be
>>> faster than thousands of fsync()s.
>> But more unsafe. The aim of frequent fsync() is to be sure not to lose
>> data.
> Yes, there is already a system wide timeout and sync, so if you don't
> care about not losing data just don't do the fsync.
Personally, I agree with this sentiment; my processor is under-powered, my
drives are old and slow, and my memory is insufficient for how I use my
machine. In short, my system is slow enough as it is. My preference would be
for no fsync()s in any but the most critical cases, and I can't think off the
top of my head, of anything a non-root user can do that I would consider that
important.
My personal take has always been the need of a configuration setting
(environment variable, with gconf fallback, for example); choice of no fsync()s
ever, fsync() only rarely (this would not be such a case), or fsync() often for
data safety over performance.
Also, aren't they bringing in file system barriers to deal with this sort of
thing without having to fsync()? Perhaps the fsync()s need at least to be
wrapped in a function that'll use such features if they're available, or
otherwise do something like the configurable choice in the previous
paragraph...?
I say that, because I also agree with the sentiment that some people don't know
better, and blame GTK for their own ignorance. Not everyone knows that the file
system can be set to write synchronously. So until those file system write
barriers become common place, or something equivalent, a changeable default of
fsync() often (what I consider to be the present situation) might be suitable.
Fredderic
------------------------------------------------------------
Bike rack
Find a huge selection and great prices on bike racks by clicking now!
http://tagline.excite.com/fc/FgElN1g4CCy4s1P6gYkQr6KocVFKldrkcaHEoo7gXRUf0IAWSRwxJ5eShzy/
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
