>On Wed, Mar 18, 2009 at 11:43:09AM -0500, Bob Friesenhahn wrote: >> In summary, I don't agree with you that the misbehavior is correct, >> but I do agree that copious expensive fsync()s should be assured to >> work around the problem. > >fsync() is, indeed, expensive. Lots of calls to fsync() that are not >necessary for correct application operation EXCEPT as a workaround for >lame filesystem re-ordering are a sure way to kill performance. > >I'd rather the filesystems were fixed than end up with sync;sync;sync; >type folklore. Or just don't use lame filesystems. > >> As it happens, current versions of my own application should be safe >> from this Linux filesystem bug, but older versions are not. There is >> even a way to request fsync() on every file close, but that could be >> quite expensive so it is not the default. > >So now you pepper your apps with an option to fsync() on close()? Ouch.
fsync() was always a wart. Many of the Unx filesystem writes didn't that is was a problem, but it still is. This is now part of the folklore: "you must fsync". But why do filesystem writers insist that the filesystem can reorder all operations? And why do they believe that "meta data" is more important? Clearly, that is false: how else can you rename files which the system hasn't written already? I noticed that our old ufs code issued two synchronous writes when creating a file. Unfortunately, it should have used three even when we don't care what's in the file. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
