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

brent@eng.sun.com

Message-ID: <3FD65144.9040406@eng.sun.com>
From: Brent Callaghan <brent@eng.sun.com>
Subject: Re: [nfsv4] Global namespace for v4.1?
Date: Tue, 09 Dec 2003 14:48:36 -0800

Seems that in building this kind of support for fs_locations
and server-server fs discovery, you're building a private
name service for NFS.  This would be fine if there weren't
already lots of general purpose alternatives, e.g. Active Directory,
LDAP, DNS etc.  These alternative name services have already
implemented such features as master-slave replication,
security, update protocols etc.  Wouldn't it be better to
leverage these existing standards, implementations, and
deployments ?

Rather than bounce clients around from server to server
via MOVED/fs_locations, why not have the client query
the name service once and go directly to the right place ?

Then, if a MOVED error does occur (rare we hope), the client could check
fs_locations (per the spec) and if it's null, just re-query the
name service - from whence it got the original reference ?

Rather than add to the list of NFS v4.x extensions, or write a
new server-server fs discovery protocol, why not work on an
LDAP schema and a description of its use by NFS ?

	Brent

Noveck, Dave wrote:
> There has been some discussion to the effect that v4 extensions to 
> support a global namespace should be done in v4.1.  I'm not sure 
> if this was on the working group list or not, but I have had some 
> discussions with people about this at interoperability events.
> 
> Given the desirability of drawing a line under v4.1 and getting going
> on actually producing the thing, I'd like to understand where this 
> stuff is, if anywhere.  Is anybody currently working on this with 
> the intention of producing a document soon?
> 
> On the assumption that the answer to the question above will be 
> negative, let me offer my suggestions on the minimal set of namespace-
> related changes that should be done in v4.1.  It is a very small set, 
> since the basics of migration give you most of what you need, already.
> 
> The existing migration support would allow you to have a single server 
> represent within a single namespace all of the fs's within a large set 
> of servers.  All you would have to do is to return MOVED for anything 
> not actually hosted on this server and have fs_locations direct the 
> client to the correct location.  The existing text about MOVED does 
> not really properly address the situation of descending into a new 
> fs which isn't there and so the suggestion that the server will only 
> return fs_locations needs to be amended to suggest that fsid as well 
> will normally be returned.  No big deal.
> 
> The only other thing that I think is needed is a little more work 
> to explain how a client should deal with various fs unavailability 
> situations.  These are all things that you could argue a client might
> derive from the existing spec plus a store of good sense, but 
> since definitions of "good sense" tend to differ, I think the spec 
> should lay these out.
> 
> The things I'm thinking about are:
> 
>      If you are directed via migration to a server which becomes 
>      unresponsive, you should go back to the source that directed 
>      you there to see where the server for this fs is, and not assume 
>      it will never move.
> 
>      Clients should interrogate fs_locations when crossing into new
>      fs's and periodically thereafter to make sure that the best path 
>      to a resource is used.
> 
>      In connection with such periodic interrogation, if fs_locations
>      is valid but does not include the current server, this is a very
>      strong suggestion that the client should use another path/replica, 
>      as the way to access that fs, if at all possible.
> 
>      If fs_locations does include the current server but it is not the 
>      first location, this is a suggestion that the client consider using
>      another path/replica for that fs.
> 
> I think this would allow a fairly reasonable namespace facility without 
> any big protocol changes.  The problem is that it is not "global" in that 
> there is no definition of server-server protocol features to allow the
> global namespace server to find all of the relevant fs's and their status.
> The situation is similar to the basic migration situation in that we have
> tackled the client-server interactions with the server-server interactions
> left TBD.  The difference is that the server-server interactions for
> fs location discovery are considerably smaller and might reasonably fit
> within a v4.x extension, as opposed to actual server-server data migration 
> where we are talking about a significant separate protocol.
> 
> So is anybody out there of a mind to tackle the server-server fs discovery,
> issues soon, so that they might get into v4.1?  I don't have time to do it,
> even though it is very desirable.  I'm going to go ahead and try to write 
> up a draft for the stuff laid out above, the client-server stuff, but if 
> someone wants to quickly do the server-server part we could combine our 
> two drafts into a single draft that addresses global namespace issues for 
> v4.1.  Any takers? 
> 
> Note that if we don't do server-server discovery extensions for v4.1, we
> could still do this feature as a separate protocol (and therefore without
> having to wait for v4.2), but it generally winds up that the overhead of 
> even a simple separate protocol is substantial, both at the spec and the 
> implementation level.  That's why tackling this now, as a part of v4.1, 
> would be nice.
>  
>        
> 
> _______________________________________________
> 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