Subject: RE: Server "Mount" Questions

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

I think the only case in which the protocol essentially
forces a server into doing this is in crossing from
the pseudo-fs into one or more "real" exported fs's.

In all other cases, the server can avoid this requirement
by exporting a view of the fs's that hides the fact that 
(locally) one fs is mounted on a directory within 
another.

I'm curious what current clients do when they encounter
a lookup which crosses a mountpoint and they are
not doing a mount?  I don't recall this being tested 
at any of the bakeoffs, although I might have missed 
it since it won't happen with my server.

-----Original Message-----
From: Eric Kadison [mailto:[email-masked]]
Sent: Monday, July 16, 2001 3:09 PM
To: [email-masked]
Subject: RE: Server "Mount" Questions

What I'm asking is very basic:  Why must an NFS V4 *Server* be able to allow
LOOKUP requests to cross mountpoints on the server?  In what case can the V4
server ever get a LOOKUP that crosses mountpoints?  After all, issuance of a
mount is a client responsibility -- there is no defined protocol for a
client to inform a server about the existence or removal of a mount.

What I hear Brent saying is that the idea of re-exporting a file system is
possible, but it has difficulties.  It sounds like there has been no market
requirement that has caused the server vendors to have an instant solution
to this issue.  So it sounds like I'm looking for a solution to a
non-problem.

So in what case(s) does a V4 server need to be able to LOOKUP across
mountpoints?

Eric

> 
> Eric Kadison wrote:
> >  :
> > 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.
> 
> 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.
> 
> 
> > 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?
> 
> 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: Brent <[email-masked]>
Date: Mon, 16 Jul 2001 14:46:06 -0700

> it since it won't happen with my server.

I tried it experimentally on a v2/v3 Solaris server a few
years ago.  I modifed the server's LOOKUP so that it
would cross mountpoints.  

I found that the clients were perfectly happy to cross
the mountpoints - completely unaware that the fsid had
changed.

The bad news is that although it appears to be a screaming
success, in fact it's no longer POSIX compliant.  If
the client steps into a new filesystem without doing
a mount, then fids are no longer unique.  You can
expect random failures of getdents(), ln, mv, cp,
because of fid collisions.

	Brent