Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!oliveb!pyramid!sas From: sas@pyrps5 (Scott Schoenthal) Newsgroups: comp.dcom.lans Subject: Re: NFS vs RFS (actually, vs Sprite and Andrew) Message-ID: <17043@pyramid.pyramid.com> Date: 16 Mar 88 23:55:27 GMT Sender: daemon@pyramid.pyramid.com Reply-To: sas@pyrps5.pyramid.com (Scott Schoenthal) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 75 In article <8431@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >bob@allosaur.cis.ohio-state.edu writes: > Note that this is neither a philosophical problem with NFS, > nor a Pyramid-specific bug: According to conversations at UNIForum > with a person from Sun's NFS portability group, all known > implementations of NFS have this feature. > >An addendum on that: The problem is not in all known implementations; >Mark Stein of Sun's NFS development group told us in more recent >releases of NFS, the strategy using /etc/rmtab is no longer current. >I don't recall what the new strategy is that's in place, but the >/etc/rmtab bottleneck is no longer a problem. Please get your facts straight. In the standard Sun NFS Release 3.2/4.3 (the most recent one available to vendors such as Pyramid), /etc/rmtab is updated after each mount request (successful or otherwise) by the rpc.mountd. What happens is that the mountlist is written to a temporary file. The file is then renamed to be /etc/rmtab (causing the old copy to be removed). As new mounts are added to mountlist, they are linked into the head of the list. No re-ordering of the list is done. Pyramid's OSx releases 3.1, 4.0, 4.1, and 4.4 follow this strategy. Unless Sun has changed the way that the mount daemon does service dispatch in SunOS 4.0, I would suggest that you re-consider your statement on the /etc/rmtab "bottleneck". The rest of this is in reply to Bob Sutterfield's comments ... Message-ID: <8428@tut.cis.ohio-state.edu> > Installed base != scalability. We have encountered scaling > problems in existing implementations of NFS, and we worry about what > happens when we hit scaling problems in the design. I think that this is a valid concern. One of the problems that Pyramid has had as a supplier of an NFS product is in taking algorithms which were originally designed on a microcomputer and adapting them to a large(r) multi-user (and multi-processor) environment. In some sense, this is true of a lot of code that we use to build our software products: e.g., 4.x BSD. To take the mount daemon as an example. Its list of mounted paths is kept in a linked list. Ohio State mounts some 130 Suns each with 9 NFS file systems onto its poor Pyramid 98x. Linked list traversal -- over 1000 elements -- string comparisons of pathname components to find the correct element. You be the judge. Please don't take this as a knock on Sun. NFS is a very good product and the releases that are distributed to vendors are generally of high quality. I think that it's safe to say that we (both the NFS vendor and user communities) need to understand better how NFS works (by this, I mean what are the issues involved in, say, service an NFS message and forming its reply -- timing constraints, multi-processing, multi-processor, etc). and what its bottlenecks (or implementation scalabilty issues) are. I know that Sun is looking at this problem -- an excellent presentation was given at Connectathon a few months ago by Sun on some performance measurements extracted by "diddling" with various NFS parameters (# of biods, nfsds, etc.). I'm sure that other NFS vendors are looking at this as well. Among the scalability issues I see in Unix-based implementations: socket receive queue size is limited, the current lock service is top-heavy, client timeout and re-transmit parameters are derived by magic, many of the internal data structures are kept inefficiently for large quantities of data. > [ ... ] Would someone from > Berkeley or CMU care to comment upon any specific scaling problems > {\em in the NFS design} that Sprite or Andrew would solve in a large > network of diskless workstations? I'd be interested in this as well. Of course, I'd also be interested if any of the other NFS vendors (e.g., Sun, Sequent, Gould, Alliant, Convex) had comments on NFS scalability. sas ---- Scott Schoenthal sas@pyrps5.pyramid.com Pyramid Technology Corp.