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

From: Juan Gomez <[email-masked]>
Date: Wed, 10 Dec 2003 11:17:10 -0800

I think not re-inventing things that are out there is good. The only
problem I see with this is configuration. You now need to make sure that
your v4 servers are well aware of where to go when the FS is not where it
must be. I know there are other protocols that can help you there but then
you add a lot of dependencies so it boils down to dependencies and one-time
install /configuration work as opposed to have a self-contained system
where v4 covers everything from location mapping to NFS functionality.

Regards, Juan

|---------+---------------------------->
|         |           Brent Callaghan  |
|         |           <[email-masked]|
|         |           m>               |
|         |           Sent by:         |
|         |           nfsv4-admin@ietf.|
|         |           org              |
|         |                            |
|         |                            |
|         |           12/09/03 02:48 PM|
|         |           Please respond to|
|         |           Brent.Callaghan  |
|         |                            |
|---------+---------------------------->
  >-----------------------------------------------------------------------------------------------------------------|
  |                                                                                                                 |
  |       To:       [email-masked]                                                                                  |
  |       cc:                                                                                                       |
  |       Subject:  Re: [nfsv4] Global namespace for v4.1?                                                          |
  |                                                                                                                 |
  >-----------------------------------------------------------------------------------------------------------------|

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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
>

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

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

---

From: Ted Anderson <[email-masked]>
Date: Thu, 11 Dec 2003 08:22:40 -0500

> where v4 covers everything from location mapping to NFS functionality.

One approach that has been suggested by Rob Thurlow in his namespace 
I/D[1], and which Dave mentioned at the beginning of this thread, is to 
  utilize NFSv4 as a namespace protocol.  In this approach, a NFSv4 
server acts as a wrapper or proxy for some other name service(s), such 
as LDAP or DNS, but always identifies filesystems as MOVED to their 
current homes.  This allows the NFSv4 client to use the same protocol to 
traverse the namespace as to access files.  This NFSv4 name server could 
be centrally located in each organization.  Or more globally, there 
could be a network of these servers addressing different collaborative 
scales (inter-organizational, organization, department, etc) directing 
clients from one to another until a "leaf" filesystem was identified. 
Possibly, if the NFSv4 name server is really only a proxy for one or 
more name services, then you could also choose to run one on each 
machine as a namespace helper application.  Clearly, there are different 
trade-offs to be explored regarding various configuration and managment 
issues.

Ted Anderson

[1] http://www.ietf.org/internet-drafts/draft-thurlow-nfsv4-namespace-00.txt