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

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.

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

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

New features of NFS v4 - 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) => OPEN “home/data” READ at 0 for 32768 READ OK (32768 bytes)

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

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.

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.

Performance of Read Delegation

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.

Performance of Write Delegation

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

Nache Architecture the Nache proxy sits in between a local NFS client and a remote NFS server caching the remote data closer to the client. Nache acts as an NFS server to the local client and as an NFS client to the remote server.

Performance of Read and Write Delegations

Benefits of Nache

Effect of Proxy on response time over a WAN