david@elroy.jpl.nasa.gov (David Robinson) (06/02/90)
Having read the NeFS specification I consider it an interesting
approach to creating a networked filesystem between heterogenous
operating systems. But I wonder how useful it will be in the real
world.
Looking at the current implementations of NFS clients the vast majority
use some sort of virtual filesystem or filesystem switch to provide a
mostly transparent access to remote files with minimal changes to
user level code. For example: Sun VFS, AT&T FSS, PC-NFS redirectors,
VMS ACPs, and others. Few actually bury network specific code into
user level applications. If you examine each of the methods currently
used, most gain very little from using an interpreter on the server. The
example in the draft of implementing the Unix "du" facility is a nice
elegant example of NeFS. Unfortunately without a completely new,
high level system interface, all the underlying OS
and NeFS are going to see is a bunch of readdir and getattr
function calls. The interpretive nature of a server gains very little
functionality.
In addressing the hetrogenous nature, PostScript dictionaries are very
nice for providing the ability to have extensible and varying attributes
between systems. But this can almost as easily be handled with
extensible data structures without the overhead of an interpreter.
With the exception of a minority of machines such as LISP machines
there is a great lack of technology to take advantage NeFS while
preserving the transparency of user level code. NeFS is an interesting
technology but is it appropriate to solve the problems of the existing
NFS?
-David
--
David Robinson david@elroy.jpl.nasa.gov {decwrl,usc,ames}!elroy!david
Disclaimer: No one listens to me anyway!
"Once a new technology rolls over you, if you're not part of the steamroller,
you're part of the road." - Stewart Brandbrent@terra.Eng.Sun.COM (Brent Callaghan) (06/05/90)
In article <1990Jun1.231507.13779@elroy.jpl.nasa.gov>, david@elroy.jpl.nasa.gov (David Robinson) writes: > Having read the NeFS specification I consider it an interesting > approach to creating a networked filesystem between heterogenous > operating systems. But I wonder how useful it will be in the real > world. > > Looking at the current implementations of NFS clients the vast majority > use some sort of virtual filesystem or filesystem switch to provide a > mostly transparent access to remote files with minimal changes to > user level code. For example: Sun VFS, AT&T FSS, PC-NFS redirectors, > VMS ACPs, and others. Few actually bury network specific code into > user level applications. If you examine each of the methods currently > used, most gain very little from using an interpreter on the server. The > example in the draft of implementing the Unix "du" facility is a nice > elegant example of NeFS. That's all it is, just an example of what you can do with an extensible protocol. It's not an implication that you can do this within the constraints of the current VFS interface. The "du" example illustrates two important points: - The server doesn't explicitly support "du". The client programmed this functionality into the server. - In a high-latency network (a WAN) a "du" is vastly more efficient than the equivalent function translated into NFS requests. > Unfortunately without a completely new, > high level system interface, all the underlying OS > and NeFS are going to see is a bunch of readdir and getattr > function calls. The interpretive nature of a server gains very little > functionality. Unix VFS interfaces should not be used as a constraint in the design of a distributed file system. VFS interfaces are easy to modify and extend, network protocols are not. A network protocol must not restrict the evolution of VFS's: Unix, OS/2, MacOS... > In addressing the hetrogenous nature, PostScript dictionaries are very > nice for providing the ability to have extensible and varying attributes > between systems. But this can almost as easily be handled with > extensible data structures without the overhead of an interpreter. No, you have it in reverse. The decision was made to investigate an interpreted protocol. We already had the notion of "extended attributes" as key/value pairs from NFS3. It was natural to represent extended attributes as a dictionary in the language of choice: PostScript. > With the exception of a minority of machines such as LISP machines > there is a great lack of technology to take advantage NeFS while > preserving the transparency of user level code. NeFS is an interesting > technology but is it appropriate to solve the problems of the existing > NFS? Distributed filesystems technology still has a long way to go. NFS, RFS, AFS are just the first examples of this technology. It's important to design protocols that not only support current needs but can be easily extended to support future needs. An example: The Mac filesystem ops do not fit well into the NFS protocol. This becomes even more true with MacOS V7.0 which supports a "find file" operation **on the server**. Ditto OS/2 2.0: it supports user-defined file attributes as key/value pairs. It's just a matter of time before Unix says "me too" and the various VFS interfaces evolve to accomodate the new feature. -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051