[NTLUG:Discuss] Re: A UNIX/Linux Staple: The Automounter -- ???

[Eric Schnoebelen]

"Bryan J. Smith" writes:
- [ Here we go, "analness" ... ;-]

	Sorry, but I didn't/don't want people using/believing
potenially incorrect information about NFS..

- On Sun, 2004-09-26 at 02:59, Eric Schnoebelen wrote:
- > I've got to take exception to your claims that NFS is stateful..
- > It's explicitly designed to be stateless (until version 4, which
- > isn't in deployment yet..)
- 
- I meant the operations are stateful.

	I'm not sure what you mean here..

- > Every NFS request has to care sufficent information for the server
- > to be able to determine the request being made.  In fact, as long as
- > the client doesn't make a request, it may never know if the servers
- > gone down or not...
- 
- Again, I meant the operations are stateful.  I actually consider it an
- advantage.  Depending on the options of the client, 

	Yes, it can be an advantage, but it also demonstrates
the statelessness of NFS on the server..  All state has to be
held on the client..

- > Thus, on a UNIX system, it looks like /foo/bar/baz, but on a VMS system,
- > it looks like [foo.bar.baz].
- 
- NFS is pretty UNIX/inode filesystem-centric.  Although you can use NFS
- for VMS, NT, DOS, etc... it's operations are limited in such regard for
- those clients.  In those cases, the clients do handle some
- accommodations.

	While it was designed by a UNIX vendor, for use with
their diskless workstations (replacing a network block server),
it was designed sufficently general to pretty easily abstract
out the UNIX-centricities..   And most implementations do..
There is no inhierent knowledge of the UNIX filesystem
implementations required for a client to use a UNIX based
server.

- > Files are presented to the client as byte streams at the VFS layer,
- > which generates the file system representation appropriate to the
- > client system.
- 
- Not always.  Depends on the client.  Many UNIX clients, including Linux,
- access the mounted filesystem as if local, right down to reading inodes
- and blocks -- dentry-level and similar access.  Again, clients _can_ add
- some layers of abstraction, if they do not handle things in such a
- manner.

	Most UNIX client's don't make any assumptions about the
data they get back from the NFS server, other than they've got a
token that refers to file, and (basic) type information about
the file.. (aka, regular file, directory, or device node.)

	The Linux client's "knowledge" that the server token it
is handed back actually represents an file-system/inode/block
combination has actually caused failures between Linux clients
and other NFS servers..  In fact, NetBSD has a special export
mode on NFS just to cope with this particular bit of broken-ness
on the part of Linux NFS clients..

- So I'm talking the typical UNIX-to-UNIX NFS access.  It's rather direct,
- with_out_ a lot of "re-presentation" in most kernel implementations for
- both the server and client.  Other client platforms are often not the
- same.

	See above.  Those "assumptions", when placed into the
kernel NFS client code, cause the implementation to be broken
against other NFS servers..  

-                                                        Now Linux's
- kernel NFS implementation was rather "non-compliant" (with RFC NFS v2)
- until the SGI-Trond patches late in the 2.2 series (standard in 2.4). 
- But 2.4 is considered fairly NFS v3 compliant to an extent.

	Huh??  There seems to be a number of weasle words
there..  Either it's compliant (and passed at Connect-a-thon) or
it's not.. 

--
Eric Schnoebelen		eric at cirr.com		http://www.cirr.com
  Fortune: What I want is all of the power and none of the responsibility.