Subject: RE: [nfsv4] Crossing mount points without a mount protocol

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 5 Dec 2003 06:33:00 -0800

I realize that what I propose below may not be easy to implement in
any particular environment, but I think the following is within 
the spirit of the protocol.

I think the problem is when you say:

> In version 4, the client must LOOKUP thru "d" to get to "e", which will
> fail with EACCESS.

Clearly failing with EACCESS would be a bad thing here.  Note the 
analogy with a/b in your example.  a/b is not accessible either, but
the client will do a lookup for c within it and not get EACCESS.
The reason is that you don't let the client see the "real" root
fs, but he instead sees a pseudo-fs in its place.  It is accessible
(no EACCESS for the client) but we can make it accessible just because
the client cannot see the real thing, but the incredible (well not 
so incredible) facsimile that only lets him do as much as is necessary 
to find the fs's that he can access.

So it seems to me that the cleanest way to deal with your issue is to
present a/b/c/d as a second pseudo-fs which has just enough functionality
to allow the client to find the real fs a/b/c/d/e.  The client does 
not see the real a/b/c/d, just as he doesn't see the real a/b.

The tricky case is when only a subset of clients can access a/b/c/d
(or a/b).  In those cases, some clients will see the real a/b/c/d
while other will see the pseudo-fs replacement.  

-----Original Message-----
From: Steven Huntington [mailto:[email-masked]]
Sent: Thursday, December 04, 2003 11:37 AM
To: [email-masked]
Subject: [nfsv4] Crossing mount points without a mount protocol

Hi all, I had a question about Pseudo NameSpace in a multi-FS environment.

Consider the following in an "exports" file, indicating what a client can
mount on my server (including descendants of that object):

/a/b/c

And suppose there is an FS addressed at "/a/b/c/d" which is INACCESSIBLE to
the client, and "/a/b/c/d/e" which is accessible.

In version  3, a client could issue a mount command to /a/b/c and
/a/b/c/d/e and could use the resultant filehandles to access the FS's which
were appropriate.

In version 4, the client must LOOKUP thru "d" to get to "e", which will
fail with EACCESS.

We would prefer not to change the name space to "virtualize" the path to
the filesystem at "e" (i.e. set up a name space at /mnt/c and another at
/mnt/e) as our customers would have to change their local exports files
depending upon whether they run v3 or v4 (client has an established
knowledge of the existing path to FS "e").  Adding a second export entry to
indicate /a/b/c/d/e is also not preferable, same reason.

Any thoughts on how the v4 mount-emulation idea is supposed to work with
POSIX in a situation like this one?  Our NFSS is generally just a traffic
director and does not necessarily know where filesystems reside (we were
counting on the mount protocol in v3).

Cheers,

Steve Huntington, IBM San Jose

Phone:            (408) 256-1948 (T/L 276-1948)
Fax                   (408) 256-2500
Office:              San Jose 50-C398
Internet:          [email-masked]
Lotus Notes: Steven Huntington/San Jose/IBM@IBMUS

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4