Subject: [nfsv4] fs_root in fs_locations structure

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 11 Dec 2003 06:37:03 -0800

Looking at migration and namespace issues in excruciating detail in
order to understand what, if anything, we need to do for nfsv4.1,
I've come across some issues with the third paragraph (excluding
the structure definitions themselves) in section 6.3 of RFC 3530.
Basically, the problem is that I don't understand what the purpose
of fs_root is, and rereading the paragraph desn't seem to help.
So I thought I'd see if other people think they understand this
any better.  While this is a game any number can play, I'd really
like to have the person who actually wrote these words (Spencer?)
explain what the intention was.

I'd like to get this resolved quickly so I can find out whether
we need any changes for v4.1 at all.  I had thought that v4.0 had
99.9% of what was needed for a single server to direct clients to 
a large set of fs's on multiple servers but it may in fact be 
100% in which case, I don't have to write this I-D :-), and people
can implement this and deploy without waiting for v4.1 :-)

   The fs_locations struct and attribute then contains an array of
   locations. 

No problem. 

   Since the name space of each server may be constructed differently, 
   the "fs_root" field is provided.

If the namespace of each server were constructed the same, then fs_root
wouldn't be required?  

   The path represented by fs_root represents the location of the filesystem 
   in the server's name space.

OK, but why do you need this?  You accessed some filehandle which you got
by traversing the server's namespace, crossing fs junction points and noting 
new fs's.  Were you assumed to be sleeping all this time?  Why wouldn't
the client be assumed to know this stuff?  Also, this opens up the problem
of what the client is to do if fs_root is wrong.  Suppose you are in 
/ietf/nfsv4/specs and get a MOVED error and fs_root in FS_LOCATIONS says
/ietf/ldap/server moved?  

However, there is one case I can see in which the client might not have 
the right fs and this is the case that I'm worried is not properly handled  
in v4.0.  You cross into a new fs and immediately find it has moved (or 
isn't there anyway).  I had worried that since the client might not check 
the fsid attribute and the server might not support it in this case, you
wouldn't know that the new fs, rather than enclosing fs, had moved.  But 
it looks like fs_root would handle this case, and that may even have been
part of its intention.  Anybody know?

   Therefore, the fs_root path is only associated with the server from which 
   the fs_locations attribute was obtained.

OK, but ...  

   The fs_root path is meant to aid the client in locating the filesystem at
   the various servers listed. 

How does it do that?  You just told me that it only applies to the source
server, and repeated it, to make sure I understood that.  Now you say it 
helps locating the fs on the destination, where it doesn't apply.  So how
can it do that?  What am I missing?

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