Re: [nfsv4] Global namespace for v4.1?

cburnett@us.ibm.com

Subject: Re: [nfsv4] Global namespace for v4.1?
Message-ID: <OF39B8EC69.75D83C31-ON87256E04.00694EBE-86256E04.006ECD31@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Mon, 22 Dec 2003 14:12:16 -0600

"David writes:
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."

---

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 cburnett@us.ibm.com)

David Robinson <David.Robinson@Sun.COM>
Sent by: nfsv4-admin@ietf.org
12/22/2003 12:31 PM
Please respond to David.Robinson

        To:     nfsv4@ietf.org
        cc: 
        Subject:        Re: [nfsv4] Global namespace for v4.1?
.
.
.
.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4