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

From: Jon Haswell <[email-masked]>
Date: Mon, 29 Dec 2003 10:16:25 -0800

Dave Noveck wrote:

> Microsoft's Dfs works in a similar manner, while it does allow the
> server to indicate a redirection, the client still looks up in AD
> where to go.

I mean't to respond to this comment before Christmas but I needed to do a
little more research before I did. Firstly, after checking with my friends
in the Samba community, I think the above comment might be misleading -
depending on what you defined AD as. I believe the following happens in
CIFS

 - client tries to access a file or directory

 - server gives a "path not covered" error. It does not at this stage
   give any indication as to where the real location is.

 - client notices the "path not covered" error and sends a TRANS2
   GetDfsReferral request to the server that gave it the "path not
   covered" error. The GetDfsReferral request contains the path that
   the client wanted, relative to that server.

 - the server responds with a new path (or multiple paths), in full
   UNC format. The UNC format contains both a server name and a
   relative path name on that server.

 - the client connects to that new server and retries the access

Now I don't know if there are some special cases that don't follow this
pattern, but this to me says that CIFS and NFS V4 are very similar in that
the client goes back to the server returning the error code to find the
actual data location (in the NFS V4 case at the FS granularity in the CIFS
case at the directory/file level). How the CIFS file server gets the
information on where the data now resides I presume would be covered by the
'in Active Directory' comment.

Looking forward I think it is important that, as somebody else said, we get
as wide an adoption of the global namespace as possible but also that we do
not become dependant on every protocol/client supporting it before we move
forward.

I would hope to see a model where we have a single global namespace based
on LDAP or the like. It's client would be NFS V4 servers, CIFS servers and
possible NFS V3 automounters and the like.

For file serving protocols that support client direction via the server,
then clients obtain their location information via the native protocols and
only via their native protocols unless they are given specific permission
by the servers to do otherwise, i.e. I would see a possible way to support
this being an additional attribute on an FS which allows a client to access
the global namespace bypassing the server, if set, for anyfile system
mountedd within the filesystem to which the attribute is returned.

Jon Haswell
IBM Research
Tel 408 927 2074 Tie 457 2074
Fax 408 927 3030 Tie 457 3030

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 29 Dec 2003 10:27:50 -0800

-----Original Message-----
From: Jon Haswell [mailto:[email-masked]]
Sent: Monday, December 29, 2003 1:16 PM
To: [email-masked]
Subject: [nfsv4] Global namespace and multiple file access protocols

Jon Haswell
IBM Research

---

From: Jon Haswell <[email-masked]>
Date: Mon, 29 Dec 2003 10:35:32 -0800

My apologies - it was not Dave Novak but David Robinson who made the
comment on CIFS DFS, my note should have read

Jon Haswell
IBM Research

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 30 Dec 2003 11:50:16 -0800

So I have a bit of confusion about this issue (OK, maybe more
than a bit), but here is the current problem:

Jon bases his Prohibitionist stance (as opposed to the people
who want direct access to 180-proof LDAP :-), on the idea that
servers in clusters will want to load-balance or otherwise 
manage client access in ways that don't map well to the more 
permanent kinds of namespace configuration stored in a name 
service.  

I can see the cases where that would make sense, but where I'm 
having trouble is with his current mapping of this to protocol.  
Clearly CIFS and v4 will do this in their own separate ways (and 
a multi-protocol server will load-balance among all of the clients
of whatever protocol).

So the problem I see is with NFS Classic (i.e. v2 and v3), for which
there is no within-protocol referral mechanism, making prohibition
impractical.  The problem is that the argument for prohibition,
that the server NFS server needs to load-balance, would seem to 
apply with equal force to NFS Classic and NFS-v4.  The only difference
is that NFS Classic doesn't support migration, making it even more
important to select the proper server, while, by hypothesis, the 
LDAP server won't be able to do that, leaving the automounters with
access to LDAP but not to the load-balancing info that the NFS server
is maintining and delivering to v4 clients.  

So what's the answer here?  Should we let the automounters drink 
themselves silly, or is there a way to get them into a treatment
program :-)

-----Original Message-----
From: Jon Haswell [mailto:[email-masked]]
Sent: Monday, December 29, 2003 1:36 PM
To: [email-masked]
Subject: [nfsv4] Fw: Global namespace and multiple file access protocols

Jon Haswell
IBM Research

---

From: Jon Haswell <[email-masked]>
Date: Wed, 31 Dec 2003 10:51:05 -0800

On Tuesday, 12/30/2003 at 11:50 PST, "Noveck, Dave"
<[email-masked]> wrote:
<snip>

> who want direct access to 180-proof LDAP :-),

So do I get to play Eliot Ness to your Al Capone ?

> is maintining and delivering to v4 clients.

I see load balancing to be handled differently for different protocols,
with different characteristics availale with the different protocols. We
handle NFS V4 and CIFS via the protocols built in support for redirecting
clients between servers. This can't happen with NFS V2/V3 so we have
alternative mechanisms for these protocols, for example layer 7 switches
that because V2/V3 is so relatively simple and stateless can front end a
cluster and redirect the packets to the back end servers. These switches
are expensive and difficult to implement for V4, due to the state and
session basis of the protocol, hence we wish to have a way to avoid them
for CIFS and V4.

There are pluses and minuses for the V4 model of redirecting clients
between cluster nodes and the V3 model of virtualization - you get what you
pay for, and I don't see us extending V3 to allow on the fly redirection or
to make V4 stateless :-)

> themselves silly, or is there a way to get them into a treatment

So the answer is licensing of the availability of LDAP and the removal of
organized crime as a result...

1) When a client is first booted, regardless of the protocol it supports,
it may either find the root of the namespace by going to a well known
server serving using it's protocol or alternatively query LDAP.

2) When a client has started interacting with a server and every time it
crosses into a new FS it must virtually query if locations for FS's mounted
within this FS should be located via the file serving protocol or
externally via LDAP.

3) If the protocol the client is using is V2/V3 then the implied result of
the FS query in 2 is LDAP via automounter

4) If the protocol the client is using is CIFS then the implied result of
the query is inband CIFS i.e. TRANS2
GetDfsReferral to the CIFS server.

5) If the protocl the client is using is V4 then a real query must made to
the server and the result returns depends on the implementation of the
server.

In this way we can have a V3 automounter setup that plugs into a global
namespace and if the V3 server is a cluster it can load balance via a
virtualizing switch or whatever. We can also have a V4 server that fits
into a global namespace but may expose subFS's that it dynamically moves
between it's nodes and that clients can track without modifying the global
namespace view in LDAP.

Everybody happy now ?

Happy New Year

Jon Haswell
IBM Research