NFS future enhancements?
J Q Johnson
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 Harris
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
g...@sun.com (or g...@sun.arpa)
Guy Harris
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.)
Rick Adams
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
Jeff Siegal
>(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
Doug Gwyn
>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).
It gets even worse on System V NFS implementations, since one loses
record locking and has an implementation conflict with RFS. Needing
a global user ID space ("yellow pages") is also unacceptable in many
applications.
It's sad that NFS seems to be spreading as the "de facto" standard
remote file approach when its original design deliberately avoided
solving the really hard problems. Either LOCUS or RFS (the AT&T
trademarked one, not the U.Wisc. research thing) has much better
technical properties. If LOCUS, Inc. or AT&T want to do something
about this, they better hurry. One thing Sun does seem to have done
right with NFS is to help make it widely available, and that may be
what settles the matter.
Sun, DEC, and AT&T have all taken quite similar approaches to the
"generalized file system"; this would be a good time to produce a
merged version that could be used for all of these various net file
system implementations. Perhaps then NFS-2 could support full UNIX
semantics on UNIX systems and emulate whatever it can on MS/DOS
(which I personally don't care about), with support for the
"advertise remote mountable file system" and user ID mapping
features of RFS. Do these guys talk with each other? Why do we
keep slugging it out in the marketplace when cooperation would
benefit all involved (including the customers)?