Network File System (NFS) Pradipta De pradipta.de@sunykorea.ac.kr
Today s Topic Network File System Type of Distributed file system NFS protocol NFS cache consistency issue CSE506: Ext Filesystem 2
NFS Overview Distributed File System easy sharing of the data across clients centralized administration Other Distributed FS Windows SMB, Andrew FS, Lustre (parallel distributed FS)
Basic Operation idea File Server hosts the File System and storage disks Client side runs an application to make file requests Network layer communicates each request from client to file server, and once the response arrives it is delivered to the requesting client side app Ideally no change to the file system interfaces
How does NFS work? VFS layer was introduced while NFS was being designed RPC hides the details of the network communication it uses UDP or TCP XDR: data exchange representation is an important interoperability layer enabling machines of different architecture to interact makes NFS machine independent
Key Design Features Machine and OS independent Crash recovery Making protocol stateless Transparent access VFS layer Unix semantics on Unix clients Unix semantics must hold on the server Performance Must be faster than remote transfer of files
NFS Protocol (summary) Mount remote file system: mount system call Routed through VFS Daemon on the server side, rpc.mountd checks the exported file systems on server Successful mount reply is a file handle for the FS File System Operations Read request VFS layer locates NFS mount point RPC layer sends GETATTR rpc request for directory LOOKUP request for locate file GETATTR for file A file handle is generated to mark the open file File Handle: combination of <volume or FS identifier, inode number, generation number>
Pros/Cons of the Design Stateless server design Server does not keep track of open files, clients connected, etc Helps in crash recovery since no complex state recovery protocol required Every client request must send all the information (server stores no information)
Crash Recovery What happens when server fails Client can retry a request multiple times More general scenario: Request lost, response lost, server crash Key idea: make the request idempotent A request generated multiple times gives same response Are writes idempotent? As long as it contains the exact offset to write to (client maintains the offset) Which request is not idempotent? create directory : mkdir
Use of generation number Client-1 (C1) creates a file F1 an inode (i1) is assigned to the file on server C1 gets a file handle Client-2 (C2) deletes the file F1 Then C3 creates another file F2, which gets same inode number (i1) When C1 tries to access F1 using i1, it will access F2 (since it will use inode i1) SOLUTION: increment generation number every time a inode is reused Check generation number (part of file handle) before allowing access
Client side Caching Network speed cannot match local disk bandwidth Cache data in client memory Read caching helps in making subsequent reads faster Temporary buffer for writes delay the write back to the server Makes writes appear faster to client since call return after writing to buffer update to server performed asynchronously
Cache consistency problem Read caching problem Unaware of updates if other clients modified server copy of the file Stale cache Soln: use a getattr call to check the timestamp of last modification of the file on server May lead to too many getattr call Use a file attribute cache use a timeout before updating file attributes from server Write buffering problem Some client may read old copy from the server Update visibility problem Soln: Flush-on-close When a file is closed by an app, flush all changes (dirty pages in cache) to the server What happens when multiple clients open same file?
Server Side buffering Read caching in memory on server helps Write buffering in memory on server is incorrect Any modified data (from write call) must be committed to stable storage before returning success If server fails before committing the write to disk, client will not know that it must reissue the write request
Time Sync Clocks on different clients may drift in CPU time Many app uses the modification time of files to tell the last change Getattr call fetches the timestamp Run Network Time Protocol (NTP) to keep client clocks synchronized with the server
NFS: latest versions Version 3 Uses TCP (earlier version used UDP) Some request bundling to reduce network traffic Version 4 Security enhancements for enterprise env The protocol becomes stateful!! pnfs: parallel NFS split the control and data path (separate protocol server, and storage units which can be accessed simultaneously)
Putting It Together NFS Design choices Protocol Issues and solutions CSE506: Ext Filesystem 16