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

cburnett@us.ibm.com

Subject: RE: [nfsv4] Global namespace for v4.1?
Message-ID: <OF1122B9BB.6E567F9C-ON87256E04.007CD29F-86256E04.007F7A98@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Mon, 22 Dec 2003 17:14:25 -0600

So let me see if I understand:

A client issues:

LOOKUP(foo) - foo is root of fs that lives on another server
GETFH
GETATTR (requesting a slew of attrs)

Is you proposal that the LOOKUP will succeed, the GETFH will get a 
filehandle, but the GETATTR will only return fs_locations and a fsid, 
where the fsid is effectively a one time use flag to make the client 
recognize its crossed into a new filesystem that only provides location 
attrs? The client recognizes this unique sequence and immediately knows it 
needs to do the lookup sequence again at the provided server. If the data 
is replicated then the client would choose one of the provided lists of 
servers.

Is that the nuts and bolts of it?

Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

"Noveck, Dave" <Dave.Noveck@netapp.com>
12/22/2003 04:18 PM

        To:     Carl Burnett/Austin/IBM@IBMUS, <nfsv4@ietf.org>
        cc: 
        Subject:        RE: [nfsv4] Global namespace for v4.1?

> 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.

I wouldn't expect there to be much state for you to forget.  If you do,
LOOKUP-GETATTR (fs_locations), then you will have the referral destination
but no filehandle to forget or otherwise dispose of.  Unless you can do
a GETFH on an absent fs (which I don't think you can), the "virtual" fh
simply evaporates.  As far as attributes, the spec indicates that you may 
not get many because a server is presumed not have access to attribute 
data
for absent fs's (no directories to read, no inodes, etc), and says you 
will 
probably just get fs_locations, even if you ask for more.

You can return more and I've proposed fsid to make it easier to note fs
boundaries but I can't see the fsid being remembered past the referral.
The fsid attribute is inherently server-specific since there is no
mechanism for servers to co-ordinate their fsid values for uniqueness.
It really only is useful for noting fs boundaries within a server. 

If servers do return lots of attributes for stuff in absent fs's, I
would think that clients should ignore them.  They aren't reliable.
But then again, I don't expect servers to return this dubious info.

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