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

[Bryan J. Smith]

On Thu, 2004-09-30 at 00:27, Eric Schnoebelen wrote:
> 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..

I see it opposite.

The fact that the server reports to the client if and when a commit
actually occurs to disk, regardless whether or not it is a sync or async
operation, says to me it is very stateful.  If the server goes down, it
allows the client to re-commit the operation if the client did not
receive notification of the commit.  If the client goes down, the server
can atomically handle the resolution of any in-progress operations as
well.

> 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.

Not the specific UNIX filesystem implementations, but there is the
requirement of POSIX interfaces that are very much UNIX-centric.  Most
non-UNIX/Linux platforms completely lack these interfaces.

Heck, even select Linux filesystems have to have certain NFS-required
interfaces "emulated" at the kernel VFS layer because they lack them
inherently.

> 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.)

These are all still stored in the inode.  Compared to SMB, it would be
like saying the FAT entries of a file are presented directly to the SMB
client.  Again, while protocols like SMB present a completely different
set of logical meta-data compared to the underlying local filesystem of
the server, NFS pretty much presents the same POSIX interfaces for
meta-data (as well as data) to the client that are also present in the
underlying local filesystem of the server.

> 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..

Yes, there are still some non-compliance with NFS in Linux's kernel NFS
implementations, especially on the client.  I don't disagree with that.
In fact, Linux 2.2's NFS v2 implementation was completely non-compliant
in so many ways (e.g., async operation without any NFS v3 async-like
notification that the block had been committed).

So in my discussions, I'm talking about how IETF/POSIX NFS does indeed
operate.  I fully concur that Linux's NFS is not fully compliant with
the standards, although it's getting better every day.  The Linux kernel
NFS server is fairly good, but the client is still lacking some details.

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

Against NFS servers that lack certain IETF/POSIX interfaces, of course.

> 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.. 

There is one thing I've learned about NFS in my time.
I've seen no implementation that has been fully compliant.
But I trust Sun and NetApp the most, although I have not used all
platforms.


-- 
Bryan J. Smith                                  b.j.smith at ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik