50 likes | 61 Views
This paper explores cache-consistency protocols in Sprite NFS, a distributed system that aims to bring the best aspects of Sprite to the NFS protocol. It discusses the challenges of maintaining cache consistency and proposes solutions such as whole file vs block-based caching, stateless vs stateful servers, and different cache consistency models.
E N D
Distributed systems • Spritely NFS: experiments with cache-consistency protocols. Srinivasan, V. and Mogul, J. SOSP '89 • Distributed systems: large overhead between client and server • Maintaining cache between clients and server is a big challenge: whole file vs block based caching, stateless server vs stateful server, and cache consistency models CSE 542: Operating Systems
NFS • Stateless server: clients submit all requests parameters with each request • Write-through: clients cannot leave writes in cache because if clients fail, write is lost • Block cache: not whole file, periodic check with svr • Easy crash recovery: if server crashes, the system is down while the server is down but will come back just fine. If client crashes, nothing is lost because all writes are write-through. • Different than UFS consistency: UNIX lets you operate on open files (even if deleted later). Since NFS is stateless, all requests might be validated. CSE 60641: Operating Systems
Sprite DFS • Stateful server: cached in client and server. Server knows who has opened a file (open and close are sent to the server). Single writer files need not do write-through, might never write through if file was deleted • Write-back: If concurrently write-opened file, then server disables client cache. Writers become write-through and reads also go through to servers (more stricter than NFS) • Callbacks: use callbacks from server to clients • Guarantee consistency: as much as a local FS • Crash recovery is difficult – especially detecting CSE 60641: Operating Systems
Spritely NFS • Goal: Bring the best aspects of Sprite to NFS (NFS is simple but slow, Sprite is fast) • New system calls: • Open, close to server. No need for getattr (open returns it) • Callback: • All dirty blocks should be written back to server • Cached blocks are invalidated and disable cache • Issues with multithreading client as well as timeouts at the server CSE 60641: Operating Systems
Implementation issues • Client side: • Cache enabled, no change • Open and close are sent to servers, close can be delayed • UNIX read ahead is disabled for non-cacheable files • Call back • Delayed write policy: UNIX like 30 seconds • Server Side: State maintenance CSE 60641: Operating Systems