Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!uoregon!jqj From: jqj@uoregon.UUCP (JQ Johnson) Newsgroups: comp.dcom.lans Subject: Re: NFS vs RFS (actually, vs Sprite and Andrew) Message-ID: <1695@uoregon.UUCP> Date: 15 Mar 88 06:39:54 GMT References: <10370@ut-sally.UUCP> <720@uel.uel.co.uk> Reply-To: jqj@drizzle.UUCP (JQ Johnson) Organization: University of Oregon, Computer Science, Eugene OR Lines: 30 Keywords: NFS, ANDREW, TOCS, consistency The latest issue of TOCS (Feb. 1988) contains 2 papers from the 1987 SIGOPS Symposium that are directly relevant to a comparison of network file systems. A paper by John Howard et al discusses the VICE system (part of the C-MU Andrew project), and a paper by Nelson et al discusses Sprite, a network file system being developed at Berkeley. Both papers compare their system with SUN NFS, arguing that NFS is perceived as "a de facto standard" but that it has serious deficiencies when compared to their preferred system. Problems sited with NFS seem to fall into 2 categories: 1/ scalability to large systems, because of excessive network traffic, excessive server cpu loading, or difficulty in administration; 2/ problems with consistency semantics. For example, under SUN NFS if processes on different workstations perform interleaved write to a file the result is indeterminate. The two problems are argued to be related; since NFS is stateless the server cannot use any knowledge of client file caching, and hence caching must be minimized to insure consistency (that's my interpretation of the papers, not necessarily the authors'). Since these papers have been floating around for almost a year, I would think that by now SUN would have a response, either in the form of counter- arguments or draft revisions to the NFS spec. Would someone from SUN care to comment? I am particularly concerned by the difficulty in formally describing the consistency semantics of NFS. Granted that NFS is designed to work right "most of the time", it is troubling to be unable to reason formally about distributed systems built on top of NFS.