On Apr 24, 2010, at 4:53 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > Ross Walker wrote: >> On Apr 24, 2010, at 4:34 PM, Les Mikesell <lesmikesell at gmail.com> >> wrote: >> >>> Ross Walker wrote: >>>> On Apr 24, 2010, at 12:43 PM, Les Mikesell <lesmikesell at gmail.com> >>>> wrote: >>>> >>>>> Ross Walker wrote: >>>>>> NFS should always be 'sync' if performance isn't good, then your >>>>>> storage isn't good. >>>>> Why demand sync on remote storage when you typically don't have it >>>>> locally? >>>>> Programs that need transactional integrity should know when to >>>>> fsync >>>>> () and for >>>>> anything else there's not much difference whether you crash before >>>>> or after a >>>>> write() was issued in terms of it not completing. >>>> Yes, but 'async' ignores those fsyncs and returns immediately. >>> That sounds like a bug in the nfs client code if fsync() doesn't >>> block until all >>> of the data is committed to disk. >> >> It's not the client side I'm talking about, but the server side. We >> were talking NFS servers and exporting sync (obey fsyncs) vs async >> (ignore fsyncs). >> >> The client always mounts async, that's not the problem. > > That's different. I thought the nfs spec was always sync on the > server side and > the client says when async is OK. And there's some special case > response to > handle the case where the server rebooted between the async writes > and the > subsequent fsync(). All the NFS info you wanted, but were afraid to ask: http://nfs.sourceforge.net/ -Ross