DESIGN AND IMPLEMENTATION OF THE SUN NETWORK FILESYSTEMWhat is NFS?Paper highlightsObjectives (I)Objectives (II)Basic designThe protocol (I)Advantages of statelessnessConsequences of statelessnessThe lookup call (I)The lookup call (II)The lookup call (III)Server side (I)Server side (II)Client side (I)Remote mountClient side (II)Client side (III)File consistency issuesExampleSlide 21UNIX file access semantics (I)UNIX file access semantics (II)NFS solution (I)NFS solution (II)ImplementationHard issues (I)Hard issues (II)Hard issues (III)Hard issues (IV)Tuning (I)Tuning (II)Tuning (III)My conclusionDESIGN AND IMPLEMENTATION OF THESUN NETWORK FILESYSTEM R. Sandberg, D. GoldbergS. Kleinman, D. Walsh, R. LyonSun MicrosystemsWhat is NFS?•First commercially successful network file system:–Developed by Sun Microsystems for their diskless workstations–Designed for robustness and “adequate performance”–Sun published all protocol specifications –Many many implementationsPaper highlights•NFS is stateless–All client requests must be self-contained•The virtual filesystem interface–VFS operations–VNODE operations•Performance issues–Impact of tuning on NFS performanceObjectives (I)•Machine and Operating System Independence–Could be implemented on low-end machines of the mid-80’s•Fast Crash Recovery–Major reason behind stateless design•Transparent Access–Remote files should be accessed in exactly the same way as local filesObjectives (II)•UNIX semantics should be maintained on client–Best way to achieve transparent access•“Reasonable” performance–Robustness and preservation of UNIX semantics were much more important•Contrast with Sprite and CodaBasic design•Three important parts–The protocol–The server side–The client sideThe protocol (I)•Uses the Sun RPC mechanism and Sun eXternal Data Representation (XDR) standard•Defined as a set of remote procedures•Protocol is stateless–Each procedure call contains all the information necessary to complete the call–Server maintains no “between call” informationAdvantages of statelessness•Crash recovery is very easy:–When a server crashes, client just resends request until it gets an answer from the rebooted server–Client cannot tell difference between a server that has crashed and recovered and a slow server•Client can always repeat any requestConsequences of statelessness•Read and writes must specify their start offset–Server does not keep track of current position in the file–User still use conventional UNIX reads and writes•Open system call translates into severallookup calls to server•No NFS equivalent to UNIX close system callThe lookup call (I)•Returns a file handle instead of a file descriptor–File handle specifies unique location of file•lookup(dirfh, name) returns (fh, attr)–Returns file handle fh and attributes of named file in directory dirfh –Fails if client has no right to access directory dirfhThe lookup call (II)–One single open call such asfd = open(“/usr/joe/6360/list.txt”)will be result in several calls to lookuplookup(rootfh, “usr”) returns (fh0, attr)lookup(fh0, “joe”) returns (fh1, attr)lookup(fh1, “6360”) returns (fh2, attr)lookup(fh2, “list.txt”) returns (fh, attr)The lookup call (III)•Why all these steps?–Any of components of /usr/joe/6360/list.txtcould be a mount point–Mount points are client dependent and mount information is kept above the lookup() levelServer side (I)•Server implements a write-through policy–Required by statelessness–Any blocks modified by a write request (including i-nodes and indirect blocks) must be written back to disk before the call completesServer side (II)•File handle consists of–Filesystem id identifying disk partition–I-node number identifying file within partition–Generation number changed every timei-node is reused to store a new file•Server will store–Filesystem id in filesystem superblock–I-node generation number in i-nodeClient side (I)•Provides transparent interface to NFS•Mapping between remote file names and remote file addresses is done a server boot time through remote mount–Extension of UNIX mounts–Specified in a mount table–Makes a remote subtree appear part of a local subtreeRemote mountClient treebinusr/Server subtreermountAfter rmount, root of server subtree can be accessed as /usrClient side (II)•Provides transparent access to–NFS –Other file systems (including UNIX FFS) •New virtual filesystem interface supports–VFS calls, which operate on whole file system–VNODE calls, which operate on individual files•Treats all files in the same fashionClient side (III)UNIX system callsVNODE/VFSOther FS NFS UNIX FSUser interface is unchangedRPC/XDRdiskLANCommon interfaceFile consistency issues•Cannot build an efficient network file system without client caching –Cannot send each and every read or write to the server•Client caching introduces consistency issuesExample•Consider a one-block file X that is concurrently modified by two workstations•If file is cached at both workstations–A will not see changes made by B–B will not see changes made by A•We will have–Inconsistent updates–Non respect of UNIX semanticsExampleServerx’ xx’’A BInconsistent updates X' and X'' to file XUNIX file access semantics (I)•Conventional timeshared UNIX semantics guarantee that–All writes are executed in strict sequential fashion–Their effect is immediately visible to all other processes accessing the file•Interleaving of writes coming from different processes is left to the kernel discretionUNIX file access semantics (II)•UNIX file access semantics result from the use of a single I/O buffer containing all cached blocks and i-nodes• Server caching is not a problem•Disabling client caching is not an option:–Would be too slow–Would overload the file serverNFS solution (I)•Stateless server does not know how many users are accessing a given file–Clients do not know either•Clients must–Frequently send their modified blocks to the server–Frequently ask the server to revalidate the blocks they have in their cacheNFS solution (II)Serverx’ xA BBetter to propagate my updates and refresh my cache ????Implementation•VNODE interface only made the kernel 2% slower•Few of the UNIX FS were modified•MOUNT was first included into the NFS protocol–Later broken into a separate user-level RPC processHard