Spritely NFS: Experiements with cache-consistency protocols

NFS

	Stateless
	Write-through
	Block cache
	Easy crash recovery
	Incomplete consistency
	Slow

Sprite

	Stateful
	Write-back
	Guarantee consistency
	Fast
	Crash recovery is difficult

RFS

	Stateful
	Write-through
	Guarantee consistency
	Slow
	Crash recovery is difficult

Apply Sprite cache mechanism to NFS to make it faster and guarantee consistency

New Client-to-Server Calls

	GetAttr deleted
	Open ( filename, read or write ) return values file handle cacheEnabled - client can cache the file or not old version numer new version number - every write-open increments the version number client compares the version number of its local copy if match, don't fetch the file from server but use its local copy
	Close ( file handle, read or write )

New Server-to-Client Calls

Callback ( file info so that client may find the correct local copy ) One of two action requested invalidate the file flush the file client return only after flushing the file to the server

Caching

	If cacheEnabled, no periodic refresh as NFS
	If not no caching at all Unix read-ahead is disabled

Delayed write with the same semantics of Unix

	when user calls fsync
	every 30 sec

State table maintains status of:

	open files
	closed files whose last writer may still have cached blocks This means that client does not necessarily flush its copy to the server on close of the file

No crash recovery at the time