jqj@gvax.cs.cornell.edu (J Q Johnson) (11/04/86)
With SUN NFS rapidly becomming an (the?) industry standard for distributed file systems, it becomes increasingly interesting to ask what enhancements to NFS are planned or likely in the future. SUN has at various times indicated an intention of providing record locking and support for swapping through NFS; in one document SUN claims to be "considering implementation of ... replicated data." What distributed file system features do sophisticated users see as important -- what features would you like to see added to NFS or to NFS implementations? As examples of such advanced features, consider location independent naming and file replication. Location independent naming in general seems like it would be very hard to add to an NFS framework, but perhaps NFS is powerful enough to at least support enough location transparency for some types of replication. Replication is something that I'd dearly love to have, at least for failure recovery. If a file server goes down, I still want to be able to get at my files from my diskless workstation! Full replication (with serialization) would be desirable, but disk shadowing with automatic remounting of a backup copy of my files would probably be adequate for many purposes. I'm sure you can think of other things for a wish list. Now the key question: is anyone working on such extensions to SUN NFS?
guy@sun.uucp (Guy Harris) (11/05/86)
> SUN has at various times indicated an intention of providing record > locking and support for swapping through NFS... Sun has already provided record locking, although it's not really done with NFS. There is a separate locking service, which is a different RPC service from NFS. The system calls that do record locking (the standard System V, Release 2, Version Whichever One Provides Record Locking On Your Particular Machine "fcntl" calls) go though this locking service, rather than through NFS, if the file system on which the file resides has been mounted via NFS. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
guy@sun.uucp (Guy Harris) (11/06/86)
> SUN has at various times indicated an intention of providing record > locking and support for swapping through NFS... Sun has already provided record locking as of SunOS 3.2, although it's not really done with NFS. There is a separate locking service, which is a different RPC service from NFS. The system calls that do record locking (the standard System V, Release 2, Version Whichever One Provides Record Locking On Your Particular Machine "fcntl" calls) go though this locking service, rather than through NFS, if the file system on which the file resides has been mounted via NFS. (BTW, it's not "SUN", it's "Sun Microsystems", or just "Sun". SUN is an acronym for Stanford University Network; "Sun" is part of the name of a company and is not an acronym.) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
rick@seismo.CSS.GOV (Rick Adams) (11/06/86)
I think the most wonderful thing Sun could do is enhance NFS to support UNIX SEMANTICS. (You know, things like forced append, 4.2bsd flock, etc). I thought they would take care of my flock complaints with their great new lock manager. However, apparently they didn't bother. (Hell, nobody uses flock, right? So much for Sun's OS being 4.2bsd compatible) Having to worry about the file system being local or remote defeats one of the major purposes of remote file systems. It still astonishes me that they continue to ignore the incredible majority of their customers who just want to connect Unix systems to Unix systems. We committed to Unix a long time ago. We have no need for MS-DOS nor CMS nor GCOS NFS. I suspect the overwhelming majority of their customers don't either. Of course it doesn't sound quite as nice as far as marketing bullshit goes, it would just be something that people could use. Why is it so difficult to have a set of OPTIONAL unix extensions that MS-DOS (or whatever) could return "failed-unimplemented" on? Then, some of us could get their work done with out "surprises" and the posturing visionaries could continue their babbling. ---rick
jbs@mit-eddie.MIT.EDU (Jeff Siegal) (11/06/86)
In article <8970@sun.uucp> guy@sun.com (Guy Harris) writes: >(BTW, it's not "SUN", it's "Sun Microsystems", or just "Sun". SUN is an >acronym for Stanford University Network; "Sun" is part of the name of a >company and is not an acronym.) You want to pick nits? Fine. It's "Sun Microsystems," _NOT_ just "Sun." "Sun" is a chemical manufacturing subsidiary of Olin. Jeff Siegal