Subject: RE: Differences between Root FileHandle and Public Filehandle

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 17 Jul 2001 07:47:12 -0700

Somenath Bandyopadhyay wrote:
> After reading all the discussions related to root filehandle and public
> filehandles , I am still confused with the definition of those:
> >From section 4.1.2:

> "the PUBLIC filehandle may be bound or represent an arbitrary file
> system object at the server".

"arbitrary file system object"?  I'd assume that it would be a 
directory, but the spec doesn't say that.

I may show up at the next bakeoff with a server that makes the
public filehandle a symbolic link.  Clients beware.

> But looking at the examples given in discussions , that's also true for
> a root filehandle. Then I go ahead and read the specification carefully
> for
> root filehandle...it says:

> "...is the "conceptual" root of the file system name space at the
> NFS server"...

I think this is a problem.  I would say it is the actual root of the
namespace that the server presents via the V4 protocol.  By that I
mean that from every directory in the namespace, if you keep
doing LOOKUPP, you will reach the root filehandle in a finite number
of steps (and if you keep doing LOOKUPP, you stay at the root).  I 
don't think the spec says this but I believe (well hope really) that
that's the intention.

> So what's the difference? Its just the conceptual root of the
> filesystem...so "conceptually" it can also represent
> "an arbitrary filesystem object at the server", right?

Again, I think it should be a directory.

The server is free to pick any directory to be the root but
his choice is constrained by what he wants to export.  If you can't
reach all exported fs's from that directory, then the client
can't see the namespace that you want him to see.

One thing that is implied by a lot of the discussion is that
the root is within the pseudo-fs (and in fact must be the root
of that fs), but I don't know if that is stated explicitly.

> 1) So the correct interpretation of the RFC ( as per me ) is:
> PUBLIC filehandle and root filehandle both represent "an arbitrary
> filesystem object at the server", even that object may be the same.

> This way NFSV4 server can represent two types of pseudo filesystems. But
> RFC does not say that clearly.

I don't know about two types of pseudo filesystems.

In some places the spec implies that there is only a single
pseudo-fs (by using the singular with the direct article), but
I can certainly think of cases in which there might be more than
one (exported fs /usr, non-exported fs /usr/local, exported fs
/usr/local/bin) which would force /usr/local to be in a second
pseudo fs different from / (unless you had the transcendant 
ugliness of a non-contiguous pseudo-fs).

> 2) I also interpret from the emails that, a NFSV4 client will only use
> one of those  types to start with...it really doesn't matter which one
> ( since
>     both represnt "an arbitrary......." ). Is that true?

No!  I think arbitrary can only mean "not constrained by the protocol".
If it meant truly arbitrary then there is no point in clients using
the op.  PUTROOTFH and PUTPUBFH are not intended to be random filehandle
generators.  So the nfs community (and thus the client and server)
have to agree that it means when I say "The file you want is at 
/x/y/z on server netapp17".  Is that relative to rootfh or pubfh?
I continue to think that "It depends" is not a very good answer
to that question. 

> or,

> 3) Can a NFSV4 client use both PUTROOTFH and PUTPUBFH and expose both
> the name spaces to the NFSV4 client and appliations? This part
> is not clearly stated in the RFC.

I don't think there should be two separate namespaces.  Root need not
be the server's local root but it had better be the root of the exported
namespace.  If there is a public filehandle and it is a directory (which
I hope is the case), then you should be able to reach the root filehandle
by doing a finite number of LOOKUPP's.  Otherwise the root filehandle is 
not really the root and you have a situation if which you can have two
co-equal (and different) namespaces exported by the servers which makes
things even more confusing.

> thanks, som.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 17 Jul 2001 12:27:54 -0500

> directory, but the spec doesn't say that.

I will correct that.

> don't think the spec says this but I believe (well hope really) that

The intent of the ROOTFH is exactly as you have stated.  Anything, as
you suggest, it not useful.

> of that fs), but I don't know if that is stated explicitly.

It will be. :-)

> ugliness of a non-contiguous pseudo-fs).

At some point in the distant past, we had a discussion of
non-contiguous pseudo filesystems and decided that it was bad.  Again,
I will clarify that there is one ROOT and there can be more than one
pseudo filesystem based on the way the namespace is constructed at the
server.

> I continue to think that "It depends" is not a very good answer

Arbitrary was meant to be "selected by the server".  The ROOTFH does
not have to represent to real root filesystem at the server.

> things even more confusing.

One interpretation. :-)  Are there any other opinions out there?

-- 

- Spencer -

---

From: mre <[email-masked]>
Date: Wed, 18 Jul 2001 04:02:07 -0700

> One interpretation. :-)  Are there any other opinions out there?

The public filehandle concept is roughly equivalent to the anonymous ftp
account. The difference is that the anonymous ftp server often
exists in a "chroot'ed" environment, such that "cd .." from the
anonymous ftp home directory doesn't get out out of the home
directory. Until NFS has a way to open directories via an
explicit state establishing operationsthat NFSv4's regular file
opens has, it would be very difficult to have "chroot'ed"
namespaces, or any other forms of separate namespaces,
except perhaps by returning different file handles for objects
LOOKUPed via the root file handles versus the public file handle.
This doesn't seem like something we should encourage, though
admittably there's enough rope in the current specification
to allow this.

I suggest that the NFSv4 specification discuss these issues,
and recommend that the PUTPUBFH refer to the
directory that is same directory that PUTROOTFH refers to,
or a descendent of PUTROOTFH's directory. This has the virtue
of being compatible with existing WebNFS server implementation
practice.

	-mre

---

From: Som <[email-masked]>
Date: Wed, 18 Jul 2001 17:55:09 -0700 (PDT)

> of being compatible with existing WebNFS server

Looks like WEBNFS client is the only software which is
going to make use of PUTPUBFH. 
Is there any other use of PUTPUBFH?

thanks, som.

=====
"Chess holds its master in its own bonds,
shackling the mind and brain so that the 
inner freedom of the very strongest must 
suffer"-Albert Einstein

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/