On Thu, Apr 1, 2010 at 10:03 AM, Darren J Moffat <darr...@opensolaris.org> wrote: > On 01/04/2010 14:49, Ross Walker wrote: >>> >>> We're talking about the "sync" for NFS exports in Linux; what do they >>> mean >>> with "sync" NFS exports? >> >> See section A1 in the FAQ: >> >> http://nfs.sourceforge.net/ > > I think B4 is the answer to Casper's question: > > ---- BEGIN QUOTE ---- > Linux servers (although not the Solaris reference implementation) allow this > requirement to be relaxed by setting a per-export option in /etc/exports. > The name of this export option is "[a]sync" (note that there is also a > client-side mount option by the same name, but it has a different function, > and does not defeat NFS protocol compliance). > > When set to "sync," Linux server behavior strictly conforms to the NFS > protocol. This is default behavior in most other server implementations. > When set to "async," the Linux server replies to NFS clients before flushing > data or metadata modifying operations to permanent storage, thus improving > performance, but breaking all guarantees about server reboot recovery. > ---- END QUOTE ---- > > For more info the whole of section B4 though B6.
True, I was thinking more of the protocol summary. > Is that what "sync" means in Linux? As NFS doesn't use "close" or > "fsync", what exactly are the semantics. > > (For NFSv2/v3 each *operation* is sync and the client needs to make sure > it can continue; for NFSv4, some operations are async and the client > needs to use COMMIT) Actually the COMMIT command was introduced in NFSv3. The full details: NFS Version 3 introduces the concept of "safe asynchronous writes." A Version 3 client can specify that the server is allowed to reply before it has saved the requested data to disk, permitting the server to gather small NFS write operations into a single efficient disk write operation. A Version 3 client can also specify that the data must be written to disk before the server replies, just like a Version 2 write. The client specifies the type of write by setting the stable_how field in the arguments of each write operation to UNSTABLE to request a safe asynchronous write, and FILE_SYNC for an NFS Version 2 style write. Servers indicate whether the requested data is permanently stored by setting a corresponding field in the response to each NFS write operation. A server can respond to an UNSTABLE write request with an UNSTABLE reply or a FILE_SYNC reply, depending on whether or not the requested data resides on permanent storage yet. An NFS protocol-compliant server must respond to a FILE_SYNC request only with a FILE_SYNC reply. Clients ensure that data that was written using a safe asynchronous write has been written onto permanent storage using a new operation available in Version 3 called a COMMIT. Servers do not send a response to a COMMIT operation until all data specified in the request has been written to permanent storage. NFS Version 3 clients must protect buffered data that has been written using a safe asynchronous write but not yet committed. If a server reboots before a client has sent an appropriate COMMIT, the server can reply to the eventual COMMIT request in a way that forces the client to resend the original write operation. Version 3 clients use COMMIT operations when flushing safe asynchronous writes to the server during a close(2) or fsync(2) system call, or when encountering memory pressure. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
