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

[Bryan J. Smith]

[ Here we go, "analness" ... ;-]

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 am, more or less, drawing a
comparison to SMB, who's operations are stateless in direct comparison. 
IMHO, while SMB might offer disconnection by default, it is extremely
problematic with most Windows applications.  E.g., sometimes when the
SMB mount comes "back up," you can have a corruption -- as well as if
and when it does not.

I won't get into NFS v4 because it's a major augmentation in many areas,
both in typical kernel implementation as well as new user-space
capabilities.

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

> A hard mount means that the request will never time out
> and fail..

Unlike the defaults of stateless SMB.

> Instead, the client will keep attempting to make
> contact with the server until it succeeds or the client is
> killed..

Assuming the client operation can be interrupted (which is a mount-time
option).

> Actually, the presentation of an NFS mounted filesystem is
> up to a combination of the cient and the server.

Did I not say that?  Every option I listed in my previous post was a
_client_ option.  Of course, if the server does not support it, then
there's not much the client can use.  ;-ppp

So I don't see how you are "disagreeing" with me here?

Unless you are trying to clarify things to the point where I would have
made a 25,000 word post that would be better handled by a FAQ.  I'm
kinda scratching my head here.  @-X

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

In my post, I was assuming a UNIX kernel NFS server and UNIX kernel NFS 
filesystem mount on the client.  Everything else is a whole new
ballgame.

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

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.

> I can't speak to how SMB does things, as it's been a long
> time since I looked at it. I think it's more stateful than NFS,
> as I remember having to reconnect SMB clients if the SMB server
> went down..

SMB's considered stateless.  It cannot maintain state.  There is
absolutely _no_guarantee_ of many things with SMB.  From the mount
going down, from handling mounts when the server comes back up,
etc...  Corruptions results in even the latest, unfortunately still
very networking-_ignorant, MS Office releases on clients.

NFS offers a variety of options and capabilities, depending on
version and implementation.  This includes async and sync operations,
something SMB fails to address or be flexible enough.  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.

I have not fully read up on and tested kernel 2.6 and NFS v4 yet.  But I
plan to when I have additional time.


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