Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!mit-eddie!genrad!decvax!decwrl!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.unix.wizards,comp.unix.questions,comp.bugs.sys5 Subject: Re: Remote File Sharing (RFS) - SVR3 Message-ID: <10938@sun.uucp> Date: Sun, 4-Jan-87 14:23:32 EST Article-I.D.: sun.10938 Posted: Sun Jan 4 14:23:32 1987 Date-Received: Sun, 4-Jan-87 21:55:42 EST References: <261@unixprt.UUCP> <371@oblio.UUCP> Sender: news@sun.uucp Followup-To: comp.unix.wizards.comp.unix.questions Lines: 54 Keywords: RFS, SVR3 Xref: mnetor comp.unix.wizards:494 comp.unix.questions:520 comp.bugs.sys5:13 (Why is this in comp.bugs.sys5? I've redirected followups away from there.) > It appears to me that all the vendors that purchase a license to SVR3 get > RFS for free with it, and it is ported to SVR3. > > At a cost of $25,000, plus more for later updates, license fees, and the > cost of porting it to SVR3, NFS gets prohibitive fast. 1) It already *is* ported to S5R3; ask Lachman Associates about it. 2) Other people seem to have decided that it's not too prohibitive, since they've signed up for it. > Also, NFS does not implement the full UNIX file system symantics, so > applications do no port as easily (or transparently). Also, follow > on charges for NFS versions that will (speculative) get it up to the > full file system symantics will probably cost even more. Also, the only transport layer that's supplied with S5R3 is Starlan; no TCP/IP or ISO protocol implementation comes with S5R3. (Yes, NFS has been demonstrated on top of ISO protocols.) There is an MS-DOS client implementation of NFS; there is none for RFS. NFS is supported by non-S5R3 UNIX systems; RFS isn't. No, you can't access devices over NFS. (If a diskless machine's root file system is being accessed over NFS, you don't *want* to access remote devices over NFS; were NFS ever changed to permit remote device access, there would need to be an option to indicate whether special files refer to local or remote devices. If RFS were ever changed to permit diskless machines, the same would be true.) S5-style locking does work with NFS (technically, it's not part of NFS; locks are managed by a different server). Forced-append mode isn't guaranteed to work, because a forced-append write isn't idempotent. It does make a "best effort", which amounts to an "lseek" to the current EOF followed by a write (done within the kernel, so no other process on the same machine can get in between them). Some other operations also aren't idempotent, although a server-side reply cache seems to prevent this from being a problem (at least in my experience). On the other hand, I haven't seen how well stateful servers work in an environment with more servers than a few carefully-administered central machines. When I had a disk, I exported the file system containing my home directory to other machines; I didn't have to worry about re-mounting my home directory on those machines if I rebooted my machine. Another machine I manage is used for development, so it is sometimes rebooted frequently; it exports an infrequently-used file system to several clients, and it would be inconvenient if they were forced to remount that file system ever time we needed to bring up a new kernel on the server. (It's also convenient not to have my sessions smashed if a server crashes.) I would say off the top of my head that a stateful server *could* reestablish a connection when the server comes back up, but as far as I know RFS doesn't do so. In short, you pays your money and you takes your choice. I see no evidence that RFS is a clear winner, and I will avoid speculation as I don't have enough data.