Subject: RE: Server "Mount" Questions

From: Eric Kadison <[email-masked]>
Date: Fri, 13 Jul 2001 18:42:06 -0700

> 
> Eric Kadison wrote:
> > Clarification:  Can a server that does not have client functionality
> > re-export a file system?  Is there any reason such a server 
> might want to
> > re-export a file system?
> 
> Sounds like you're speculating on a proxy server that just forwards
> NFS requests and replies like a router...
> 
> 	Brent

No Brent,  Broadband Storage is a NAS Appliance manufacturer.  I'm looking
at a server-only implementation of NFS V4.  What I'm trying to find out are
the implications of the server requirement that a LOOKUP cross file system
boundaries.  One of the possibilities seems to be a re-exported file system.

Background: an NFS V2 server kept a mount table and was informed when a
client mounted an object, but a V4 server is not informed of mounts and does
not keep a mount table yet must perform a LOOKUP across file system
boundaries.  How can the server cross a file system boundary when it is not
informed of mount operations?  Is the client's functionality preserved when
it cannot notify the server of mount operations?  Or did I miss something
here?

Eric

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 13 Jul 2001 23:56:04 -0500

> it cannot notify the server of mount operations?  Or did I miss something

? The only reason the MOUNT protocol exists is to provide a mapping from
a
pathname to a filehandle (later versions of the MOUNT protocol provide
for
security info as well).  Beyond that, the server does not use this
information
to determine how it should process LOOKUPs from the client.

In NFSv4, the PUTROOTFH operation has been provided as a method to
bootstrap
the client into the server's namespace.  From this point forward the
client
translates component names to filehandles with a combination of LOOKUP,
READDIR, and OPEN.

With NFSv4, the server is allowed the flexibility to present any
namespace
it wants to the client.  It is not required to mimic its local
representation
but many implementations may.  The server certainly isn't required to
make
all local filesystems available to NFS clients.  In fact, intermediate
filesystems may not be "exposed" to the client and this is the reason
why
the psuedo filesystem concept was created; to provide a bridge between
"real" filesystem components and the components that join these real
filesystems.

Spencer

---

From: Brent <[email-masked]>
Date: Mon, 16 Jul 2001 09:06:42 -0700

Eric Kadison wrote:
>  :
> Broadband Storage is a NAS Appliance manufacturer.  I'm looking

Ah, I think I see where you're going.  

Yes, it is possible that an NFS v4 client could cross a server mountpoint
from a filesystem that is local to the server into one which is NFS mounted.

I can't speak for other OS's, but in Solaris the exportability of each
filesystem (tmpfs, ufs, pcfs, nfs, ...) is determined by its support
for filehandles.  If it won't give you filehandles, then you can't
export it.  Historically, NFS doesn't give out filehandles, because of
the uniqueness and persistence problems I explained previously.

If you can overcome these filehandle problems and come up with an
NFS filesystem that will give out filehandles, then your server
can re-export.

> it cannot notify the server of mount operations?  Or did I miss something

As Spencer already pointed out, the server crossing of mountpoints is
quite unrelated to the MOUNT protocol.

I should also correct a possible assumption that server mountpoint
crossing is a property unique to the NFSv4 protocol.  The NFS version
2 and 3 protocols can also support mountpoint crossing in the same way
that version 4 does: if the client sees a change in the fsid attribute
then it needs to do some local housekeeping (register a mount) to keep
its POSIX semantics correct.

The reason you don't find mountpoint crossing on v2/v3 clients and servers
is because of implementation - not of protocol.  It's hard to implement, so
we didn't do it.  I have implemented mountpoint crossing experimentally on
a v2/v3 server and found that the clients quite happily crossed the mountpoint
without realizing it, i.e. they didn't check the fsid attribute.  The downside
is that POSIX semantics are violated (fids must be unique in filesystem).

	Brent

---

From: Som <[email-masked]>
Date: Mon, 16 Jul 2001 09:25:48 -0700 (PDT)

> NFS filesystem that will give out filehandles, then

Technically, if the filehandle consists of 128-bit
UUIDs ( or GUIDs for MS world ) plus the persistent
information needed then a NFS server can generate a
filehandle which is unique across space+time and also
supports persistent requirements...
Is there something else we are missing here?

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/

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Mon, 16 Jul 2001 09:29:17 -0700

> -----Original Message-----
> From: Som [mailto:[email-masked]]
> Sent: Monday, July 16, 2001 9:26 AM
> To: Brent; [email-masked]
> Subject: Re: Server "Mount" Questions
> 
> -snip-
> 

There may be hints in the file handle which the
server uses to determine access rights.
Read-only? read/write? root=0? root=-2?
> thanks, som.

	-gww

---

From: Brent <[email-masked]>
Date: Mon, 16 Jul 2001 09:40:27 -0700

> Is there something else we are missing here?

Right, that might be a useful property of filehandles.
Currently, the spec says that filehandles must be
unique for a server - but not across servers.

However, it does add a burdensome requirement to servers,
and (as yet) there are no proposals that depend on a
cross-server uniqueness property.

The re-export of filesystems imposes some difficult
implementation requirements on servers.  For example,
some client gets a filehandle and sits on it for 
months.  Meanwhile the NFS filesystem on the middle
server gets auto-unmounted. If the client tries
to use the filehandle again, will the server-in-the-
middle know what to do with it?  

NFS version 4 could provide some assistance here in
allowing re-exported filehandles to be marked "volatile".
Then the client could replay the path and trigger the
filesystem to be re-mounted on the server-in-the-middle.

	Brent