There are actually two problems here, plus a feature. First, some background; the NFS Version 2 protocol specification requires a server to record each write to permanent storage before it sends a reply to a client. This makes server and client reboot recovery very simple, and provides a good guarantee that data sent to the server is permanently stored. 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.
*
First problem:
The default value of this export option on Linux NFS servers before nfs-utils-1.0.1 was "async". If a system administrator did not specify either "sync" or "async" in /etc/exports, exportfs used "async" by default. This allowed the server to reply to Version 2 write operations and metadata update operations (such as CREATE or MKDIR) before the requested data was written to the server's disk, thereby greatly improving the performance of write operations as well as introducing the possibility of undetectable data corruption. Releases of nfs-utils starting with version 1.0.1 use a default value of "sync," which causes the Linux server to conform properly to the NFS protocol specification.
*
Second problem:
Support for NFS Version 3 in Linux 2.2's NFS server does not honor the "async" export option. Thus, by default on a system running Linux 2.2 with an old version of the nfs-utils package, NFS Version 2 writes are fast and unsafe, but Version 3 write and commit operations are safe, although slower, since they always follow the client's request for either UNSTABLE or FILE_SYNC (see question A1).
*
Feature:
When you use the exportfs command with its verbose option set, it displays the various export options in effect for each exported file system. If the "async" export option is set, it appears in the option list, but if "sync" is requested, it will not appear in the exportfs parameter list. This reflects the common usage of "sync" as the default in other platforms, but can be somewhat confusing.
Answered by
Yuvee
at
8:22 PM on December 18, 2008
