16.4.2.1. NFS writes (NFS Version 2 versus NFS Version 3)
Write operations over NFS Version 2
are
synchronous, forcing servers to flush
data to disk[45] before a reply to the NFS client can be generated. This
severely limits the speed at which synchronous write requests can be
generated by the NFS client, since it has to wait for acknowledgment
from the server before it can generate the next request. NFS Version
3 overcomes this limitation by introducing a two-phased commit write
operation. The NFS Version 3 client generates asynchronous write
requests, allowing the server to acknowledge the requests without
requiring it to flush the data to disk. This results in a reduction
of the round-trip time between the client and server, allowing
requests to be sent more quickly. Since the server no longer flushes
the data to disk before it replies, the data may be lost if the
server crashes or reboots unexpectedly. The NFS Version 3 client
assumes the responsibility of recovering from these conditions by
caching a copy of the data. The client must first issue a commit
operation for the data to the server before it can flush its cached
copy of the data. In response to the commit request, the server
either ensures the data has been written to disk and responds
affirmatively, or in the case of a crash, responds with an error
causing the client to synchronously retransmit the cached copy of the
data to the server. In short, the client is still responsible for
holding on to the data until it receives acknowledgment from the
server indicating that the data has been flushed to disk.
For all practical purposes, the NFS Version 3 protocol removes any
limitations on the size of the data block that can be transmitted,
although the data block size may still be limited by the underlying
transport. Most NFS Version 3 implementations use a 32 KB data block
size. The larger NFS writes reduce protocol overhead and disk seek
time, resulting in much higher sequential file access.