Path: utzoo!attcan!uunet!auspex!guy From: guy@auspex.UUCP (Guy Harris) Newsgroups: comp.dcom.lans Subject: Re: NFS vs RFS Message-ID: <875@auspex.UUCP> Date: 20 Jan 89 18:17:50 GMT References: <9018@cit-vax.Caltech.Edu> <7387@chinet.chi.il.us> <437@aurora.AthabascaU.CA> <340@moriaMoria.Sp.Unisys.Com> <247@bnr-fos.UUCP> <7482@chinet.chi.il.us> Reply-To: guy@auspex.UUCP (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 51 >I haven't seen a diskless RFS implemementation - normally the remote >disk has a mount point somewhere under a local "/". If I mount "/" >from mach2 as /mach2 on mach1, then /dev/tty1 is on the local mach1, >/mach2/dev/tty1 is on the remote mach2. Yes, but the disklessness is the whole point here; on both my machine and Charles Hedrick's machine, there *is* no equivalent of the "local mach1", so a remote file system implementation that didn't allow special files to refer to the local device, rather than the remote device, wouldn't work. (You could, at least in some UNIX implementations including the one being developed for S5R4, have an RFS mount option to specify whether special files could refer to the local or remote disk; I don't think S5R4 will have such an option, though.) Of course, the other problem with referring to remote devices is making things such as "ioctl" work if the memory layout of the argument to the "ioctl" differs between the two machines, or making "mmap" (yes, "mmap" will be in S5R4) work on a remote device.... (The former may be fixable with a fair bit of work on the drivers; the latter is probably unfixable - at least not without so much pain and overhead as to render it most likely useless.) >Non-RFS disk mounts on the remote below the RFS mount are followed >(although df only reports free space in the partition of the remote >end of the mount point) so in the above example you could access >/mach2/usr/xxx even if /usr is another disk on mach2. Is this true for >NFS? Not in the version distributed by Sun with their machines, or distributed for other people to port to their machines, although I think Doug Kingston made a change to the implementation to do just that when he was at BRL. >> - the NFS protocol itself doesn't include file locking. However >> Sun has a related protocol that does do locking. > >How about atomic file creation, append mode, or FIFO's? FIFOs work just fine over NFS, courtesy of some hackery to the protocol (code to implement said hackery is provided with recent NFS source releases, so other vendors can pick it up), although they work the same way devices do - the FIFO is strictly local, so while two processes on the same machine can communicate using it, processes on different machines cannot. The OS does its best to make append mode work; however, it can't guarantee that it works. It tries its best with atomic file creation as well, but I think that's not guaranteed either; the proposed next version of the protocol (Sun RPC includes version numbers in RPC calls, so you can have both clients and servers using multiple versions of the protocol at the same time) may have something to help it work.