Subject: RE: [nfsv4] Global namespace for v4.1?

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 21 Dec 2003 16:48:18 -0800

> >  > back the same redirection information without causing
> >  > an extra over the wire operation.
> > 
> > fs_locations is an attribute.
> > COMPOUND { ... LOOKUP ; GETFH; GETATTR fs_locations }
> > does it one round trip.
> 
> Nope. LOOKUP returns NFS4ERR_MOVED, according to the RFC
> that indicates that the COMPOUND must terminate.  You can't
> do either the GETFH or GETATTR. 

I believe the context here is that you are doing a LOOKUP in
an fs that is present on the server (typically the pseudo-fs)
and the current filehandle after the LOOKUP is one within an 
absent filesystem.

If the current fh at the start of the LOOKUP were in the absent
fs, then LOOKUP indeed would be required to return MOVED.  However,
in that case, you could do PUTFH-GETATTR before the LOOKUP, if 
you wanted the location information, as I imagine you would do.

Now let's consider the case in which the cfh at the start is for
a present fs and you are crossing into an absent one.  I don't
believe that in that case, you should return MOVED.  Instead,
the cfh should be updated so that PUTFH and GETATTR can be used
to get the fh and fs_locations, which is why the spec allows 
those operations (only) to be used in an absent fs.

The spec says this about MOVED:

   NFS4ERR_MOVED         The filesystem which contains the current
                         filehandle object has been relocated or
                         migrated to another server.  The client may
                         obtain the new filesystem location by obtaining
                         the "fs_locations" attribute for the current
                         filehandle.  For further discussion, refer to
                         the section "Filesystem Migration or
                         Relocation".

My interpretation of this is "current filehandle object" refers to the
one in place at the start of the operation.  If you were to say that
with LOOKUP, the cfh at the *end* of the operation should trigger
MOVED than you would have the bizarre situation in which MOVED indicated
that the LOOKUP failed and if the LOOKUP failed then the cfh would 
never be set to the absent fs, in which case there would be no reason 
to return MOVED, since the current fh would always be the one in the
present fs.  

Further, the text indicates that you can get fs_location on the current
fh to get the location of the absent fs.  That seems to contradict an
interpretation that would allow/require the server to check cfh after
the LOOKUP and create a situation in which you didn't have the fh you
would need to do what the spec indicates that you should do.
 
> As I said before, LOOKUP should be fixed.

I don't think it needs to be fixed.

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

---

From: David Robinson <[email-masked]>
Date: Mon, 22 Dec 2003 12:31:54 -0600

First off I agree that we have the mechanisms to make
LOOKUP work right, but I don't think the current RFC
is worded in a way that allows it.

> would need to do what the spec indicates that you should do.

Unlike GETATTR, the ambiguity arises from what is the cfh. In the
description of LOOKUP (14.2.13) it says clearly that if an
error occurs the the cfh will not be changed.  But it will
return back MOVED.

What do I lookup the fs_locations on?  The cfh is that of the directory
that contains the directory (or file) that was moved. The cfh is a
valid filehandle of the directory and the directory may contain
other entries that have not moved, or have moved to other places.
Also by reading the above quote, the current filehandle object has
not moved, it is still a valid directory that exists on the server.

I think the correct way to specify this is that when any operation
returns MOVED, it must set the cfh to a value that a GETATTR
fs_locations can be performed on.

	-David

---

From: Carl Burnett <[email-masked]>
Date: Mon, 22 Dec 2003 14:12:16 -0600

"David writes:

I think the correct way to specify this is that when any operation
returns MOVED, it must set the cfh to a value that a GETATTR
fs_locations can be performed on."

---

So couldn't a server just return a "virtual" fh on the LOOKUP? The virtual 
fh represents the namespace junction the server is hosting. The GETATTR 
response would contain a corresponding set of "virtual" attributes. Any 
other operation other than PUTFH triggers a MOVED error. This causes the 
client to do the GETATTR for fs_locations. The client then gets the 
locations using the "virtual" fh and goes to the real server with a 
LOOKUP.

It seems plausible in concept, but the implementation details would be 
very important. What assumptions should the client make about the file 
handle, filehandle type, and fsid? In the case of a referral where the 
client never actually makes it past the fsid's root dir, maybe the client 
should forget what it obtained from the referring server. Actually, this 
would seem true for all the attributes it received in the GETATTR that 
happened with the initial LOOKUP. Once the client gets the location data, 
it forgets all the previous state and redrives the LOOKUP to the real 
server.

While these interaction details may be worked out via discussion, 
convention, and prototyping, they ultimately must get written in the NFS 
protocol specification so people can get this stuff implemented correctly. 
This is true even if the current RFC 3530 mechanisms are sufficient. The 
semantics of the client to server flow and attribute management are 
equally, if not more, important than the data types and error codes. The 
final decided interaction also must be viable for a heterogeneous 
collection of servers sharing a namespace infrastructure, whatever that 
may be.

The priorities for evolving the namespace architecture might be:

1. Iron out the client to server protocol aspects for referrals

2. Define a schema for describing centralized namespace information. My 
preference would be one where servers are the constituents, not clients. 
Perhaps LDAP based.

3. Define a schema for centralized "bootstrap" information a client can 
use to find its "root" server.

Once #1 is done, a fair amount of practical implementation and product 
function seems possible while 2 & 3 are being defined.

Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

David Robinson <[email-masked]>
Sent by: [email-masked]
12/22/2003 12:31 PM
Please respond to David.Robinson
 
        To:     [email-masked]
        cc: 
        Subject:        Re: [nfsv4] Global namespace for v4.1?
.
.
.
.