Subject: RE: [nfsv4] Fw: Global namespace and multiple file access protocols

From: Jon Haswell <[email-masked]>
Date: Fri, 2 Jan 2004 17:31:26 -0500

On Friday, 01/02/2004 at 01:43 PST, "Noveck, Dave" 
<[email-masked]> wrote:
> I don't see how v4 can support referrals at the *file* level
> (as opposed to the directory level).
> 
> Except for that, I think we agree, but my impression is that
> Jon does as well.
> 

I think we are basically in agreeement. My understanding, 

1)in NFS V4 you can get ERR_MOVED at any time, not just when crossing an 
fs boundary. My understanding is that the ERR_MOVED implies movement of 
the entire filesystem however not just the specific directory or file 
which you were trying to access has moved.

2) CIFS is different in that can move just a directory and in theory also 
just a file, although that is not what CIFS servers usually do, i.e. the 
equivelent error code in CIFS implies the specific directory/resource that 
you tried to access has moved where as in V4 it means the FS container for 
the file/directory has moved.

3) If you want to do migration at the directory level in V4 then you need 
to have the server returned a different FSID for each directory. I see no 
sesible way to do this at the file level.

Now why did I bring up the whole issue of FS boundaries. What I am looking 
to do is take a global namespace, implemented via LDAP, and allow certain 
portions of it (leafs of the tree effectively) to have 
different/restricted lookup semantics and I'm trying to use FSs as a 
suitable namespace sub-entity to bound these portions with the modified 
semantics. Let me give an example to try and clarify this.

I have an entity in a global namespace such as

        us/ibm/almaden/prototypes/jon/foo

Now the namespace is implemented via LDAP, with the master server in 
Poughkeepsie (private IBM joke here, for some reason they put all our key 
servers in Poughkeepsie) while the actual data lives on the server that 
exports /prototypes, which is physically here in California.

The server exporting /prototypes is a cluster server made up of say half a 
dozen nodes all sharing access to a distributed filing system and all 
having their own IP name/address. The records in LDAP will list all these 
nodes as possible locations for the /prototypes export.

If a v2/v3 automounter reads these LDAP records then it will pick one of 
these to actually use and after that the client will be bound to that node 
for some indeterminate period of time which is defined by the client, or 
until it crosses into some new FS at which time I presume it goes back to 
LDAP to get the new location. 

If v4 reads the LDAP records and selects one of the nodes for /prototypes 
then when it firsts accesses the FS represented by /prototypes it will get 
a new attribute that specifies that when some operation within this FS 
returns ERR_MOVED then the client should only get the new location for 
this FS, or posisbly any FSs mounted within this FS, from this server, not 
from LDAP. This would then allow the server to, for example, export the 
directory jon as a unique FSID and dynamically change the actual node in 
the cluster that is exporting it, without ever having to go back and 
update the LDAP records in Poughkeepsie.

By using this approach we can have load balancing with v2/v3 automounter 
based on random selection of a server from the LDAP records with client to 
server node affinity lasting until client reboot or similar. With v4 
however we can have the server actively monitor and load balance itself 
moving clients between nodes on the fly.

One further thought - when we get to defining the schema for a global 
namespace it might be a good idea to include the options of different 
locations for data based upon the access prototol. If one is using a SAN 
or distributed filing system for example, for any specific file, we might 
want the CIFS clients to go to a native windows server while NFS clients 
go to a native UNIX/Linux server.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Jan 2004 16:43:44 -0600

> sesible way to do this at the file level.

Yes, fs migration in NFSv4 is fs-level, yes (though I suppose it
wouldn't be hard to make it more granular), but outside the context of
fs migration referrals are more granular.

(It's possible to have server-side referral support w/o server-side fs
migration support -- the protocol uses the same basic facility to
implement both.)

[...]
> moving clients between nodes on the fly.

The proponents of smart clients only will say that the v4 server can
still use the migration facility to load balance smart clients that used
the directory to get at the fs in question.

Nico
-- 

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