Subject: RE: Server "Mount" Questions

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 16 Jul 2001 14:25:49 -0700

Brent wrote:
> "Noveck, Dave" wrote:
> > 
> > Brent writes:
> > > 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.

> Yes, that's fine as long as everyone's happy with a
> single namespace on the server.

Obviously everyone isn't happy with that since you
aren't happy with that.
  
> 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.

I'm not sure why having multiple namespaces is useful.

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

You can't.  If you really want to have two separate
namespaces, then that's what you have to do.

But if we do that, let's make the spec clear.  Since
the pseudo-fs will typically only consist of things that
are exported (i.e. public), then calling one of these 
PUTPUBFH is just plain confusing.  How about PUTMOUNTROOTFH
and PUTURLROOTFH?  Then the client knows that the intention
is.

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

Then the spec should avoid the confusion we have been having
regarding this issue by saying, when you use PUTPUBFH: when 
you are interpreting a URL beginning nfs: and, when you should
use PUTROOTFH: all other times.
 
> 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.

Right but in those cases, you see one name space for http which
is different from the server's local name space, or one name space
for ftp which is different from the server's name space.

Here you have two different nfs-v4 names spaces whcih are
potentially different from each other and from the server's local
name space.   

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

But webnfs is a separate protocol.  Here you have a single
protocol and you want to have separate exported namespaces 
based, not on the protocol, but on the type of use.  I 
think that's not so good, but if you want to do it, the spec
should make clear when you use one and when you use the other,
which is not currently the case.

---

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

> and PUTURLROOTFH?  Then the client knows that the intention

Ya, I agree that the spec could be a bit more informative
on the intended function of PUTPUBFH.  Perhaps a reference
to the RFC's: 2054, 2055 and 2224 would be helpful.

Not sure that renaming the ops will accomplish much though.
RFC 2055 talks a lot about "public" filehandles and
directories and describes their use of URLs.

	Brent