Setup: one server that stores the data on its disks, and a number of clients that request data through well-formed protocol messages
Client-side file system
easy sharing of data across clients
backing up files can be done from the few server machines instead of from multiple clients
Note: reasons for server crash
power outage, bugs, memory leaks, network acts strangely (becomes partitioned)
Key: in- stead of building a proprietary and closed system, Sun instead developed an open protocol which simply specified the exact message formats that clients and servers would use to communicate.
Goal of the protocol: simple and fast server crash recovery
Key to Fast Crash Recovery: Statelessness
the protocol is designed to deliver in each protocol request all the information that is needed in order to complete the request.
fd: shared (or distributed) state between the client and the server
Information is ephemeral (i.e., in memory), can be lost when the server crashed
Client keeps enough information around in its memory to be able to tell the server what it needs to know
I.e. in a situation where the file is never close().
NSF: Stateless approach
each client operation contains all the information needed to complete the request. Client, at worst, may have to retry a request.
The NSFv2 Protocol
E.x. Client-side FS sends a lookup, the fd will be returned if successful. Then client can issue READ and WRITE protocol messages on a file, which, in read case, pass the file handle along with the offset. For write, a success code is returned.
From Protocol to DFS
The client-side file system tracks open files, and generally translates application requests into the relevant set of protocol messages. The server simply responds to protocol messages, each of which contains all information needed to complete request.
Handle Server Failure with Idempotent Operations
Idempotency: a request is idempotent when the effect of performing operation multiple times is equivalent to the effect of performing the operation a single time.
Requests in NFS that is idempotent
WRITE: which contains the data, the count, and (importantly) the exact offset to write data to
Some which are not
But PERFECT IS THE ENEMY OF THE GOOD (VOLTAIRE'S LAW). Accepting that life isn't perfect and still building the system is a sign of good engineering.
Three types of loss
Reply lost on way back from server
After sending the request, the client sets a timer to go off after a specified time period. If timeout, send the request again.
Improving Performance: Client-side Caching and Write Buffering
In-memory caching: first access expensive (network communication), and subsequent ones are quick (from client memory)
Temporary buffer for writes
Cache Consistency Problem
C2 might buffer its writes in its cache for a time before propagating them to the server. C3 (or other client) might get stale versions of the file
Cache might still contain the stale version of the data, even if the server side data has changed