Nache: Design and Implementation of a Caching Proxy for NFSv4

1. Nache: Design and Implementation of a Caching Proxy for NFSv4 Bo Zhao Computer Science and Engineering The Pennsylvania State University

2. Motivation & Challenge • Enterprises are moving toward distributed operations • Sharing files across office location in wide area • Sharing data • In a uniform, secure, and consistent manner • Across the global enterprise • Reasonably good performance.

3. Related Work • NFS and CIFS - work for a LAN • Low latency and high bandwidth • AFS and DCE/DFS – work for a WAN • Uniting disparate file servers into a single logical file system. • Deployment expense – not widely adopted • GPFS or Lustre - high performance & strong consistency • Expensive or difficult to deploy and administer

4. Cache Consistency • NFS – close-to-open consistency • When opening a regular file, • the client validates cached data for that file. The client queries the server to determine if the file has changed. Using this information, the client determines if the data cache for the file should be kept or flushed. • When the file is closed, • the client writes any modified data to the server. • No distributed cache coherency or concurrent write management • AFS – rely on client-side caching for performance • Callback to notify the client of updates • Close – changes become visible at the server

5. New features of NFS v4 - COMPOUND RPC • COMPOUND RPC • Many NFS operations in a single RPC call • Lower overall network delay • Example: • RPC in NFS Versions 2 and 3 => OPEN “home/data” <= OPEN OK => READ at 0 for 32768 <= READ OK (32768 bytes) • COMPOUND RPC => OPEN “home/data” READ at 0 for 32768 <= OPEN OK READ OK (32768 bytes)

6. New features of NFS v4 –Client redirection • Client redirection • Client can be redirected to another server • Build servers in distributed wide Area

7. New features of NFS v4 – OPEN delegations • close-to-open consistency • OPEN delegations • Eliminates: the need for the client to periodically check with the server for cache consistency. • when a file is only being referenced by a single client, responsibility for handling most operations (OPEN & CLOSE) is delegated to the client by the server.

8. Read Delegation • OPEN, CLOSE and READ requests • Handled locally. • All READs • without sending GETATTRs to check cache validity • All LOCK requests • sent to the server • Callback path is established for recalling a delegation • On a conflicting access to a file such as an OPEN for write, RENAME, and REMOVE. • After a delegation has been recalled • the client falls back to traditional attribute checking before reading cached data.

9. Performance of Read Delegation

10. Write Delegation • All OPEN, READ, WRITE, CLOSE, LOCK, GETATTR, SETATTR requests • Handled locally • On a conflicting OPEN by another client • The server recalls the delegation • Client commits all dirty data and return the delegation. • The conflicting OPEN is delayed until the delegation recall is complete.

11. Performance of Write Delegation

12. Nache vs Redirection • In federated system • Data on different geographically distributed physical locations • Two models for data access • Client redirection • Data shipping • Reduce frequent WAN access

13. Nache Architecture

14. Performance of Read and Write Delegations

15. Benefits of Nache

16. Effect of Proxy on response time over a WAN