Subject: RE: Server "Mount" Questions

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 16 Jul 2001 12:35:58 -0700

Brent writes:
> "Noveck, Dave" wrote:
> > 
> > Som asks:
> > > BTW, how does client decide when to do PUTROOTFH or
> > > PUTPUBFH to start with?
> > 
> > I've never been able to figure out when a client would
> > use one or the other.  My server does the same thing
> > on receiving either one.  Are there any servers out
> > there that do different things for these two ops?
> > 
> > Also, what do clients currently do?  I suspect they do
> > a mount by taking the path from mount and looking it
> > up starting at the root filehandle.  Is there anybody
> > who does anything else?
> > 
> > My feeling is that we should collapse these two ops into
> > one.

> WebNFS clients do a non-root pathname evaluation
> per RFC 2055.  Currently, the pathname in an NFS URL,
> 
> 	nfs://server/path
> 
> is defined relative to a directory to which a public
> filehandle is attached.  So, in Solaris you can
> attach the public filehandle to some directory that's
> not at the root, and provide some measure of location
> independence on the server.

But as Spencer points out, the pseduo-fs does not have to 
be the same as the real directory structure of the mount
points on the server.  This allows unlimited location
independence.  The server can present things as it wishes
to.

> I think administrators should expect it to work the
> same with NFSv4 as it does with v2 and v3.

I suppose that would be best, all other things being
equal.  But they aren't.  As you would have things, 
nfs://server/path is going to be (potentially) a 
different directory from the one you get from mounting
-t nfs4 server:/path.  So, the result of telling people
that what they want is at /path on server is
ambiguity, frustration and confusion.  If they do
nfs://server/path when you were thinking they would
mount, or vice versa, thingds are not going to work.
It seems unavoidable that a given directory may have a 
local name and a different exported name.  We have to
live with that but allowing it to have a local name
and two different exported names is asking (or perhaps
begging) for trouble.

> If your server doesn't support separation of public
> and root filehandles, then I think it's fine just
> to co-locate them.

---

From: Brent <[email-masked]>
Date: Mon, 16 Jul 2001 13:43:14 -0700

> independence.  The server can present things as it wishes

Yes, that's fine as long as everyone's happy with a
single namespace on the server.  But if the server
is providing some kind of web-like access to files
through URL's, then it can be useful to distinguish
between the server's "native" namespace, from which
conventional NFS mounts are done, and a "public"
namespace that is used for URL access.

For example, in Solaris we can have:

	share           /export/stuff

	share -o public /export/public

Where a client can:

	mount  server:/export/stuff  /mnt

to see files under /export/stuff, and use a URL

	nfs://server/foo

to see file "foo" under /export/public.

This is the way it currently works with
NFS v2 and v3.  How do we make v4 behave
the same way as v2 and v3 without the opportunity
to have a separate namespace via a public filehandle?

> and two different exported names is asking (or perhaps

Sure, there's potential for confusion, but in practice it
doesn't seem to be a problem.

To put the right perspective on it, this is about URLs.
We're familiar with http and ftp URL's.
The pathname used there doesn't take you to the server's root.
In the HTTP case, it's relative to the "document root", and for FTP
it the directory where the ftpd is chroot'ed.

All we're doing here is providing NFS with the same ability,
and compatible with the way NFS v2 and v3 handles WebNFS
clients.

	Brent