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

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 10 Dec 2003 07:23:43 -0800

I think we need to separately consider the client-server part of this, from
the server-server part, and if we do that, we have a lot of choices, including
the one you suggest below.

With regard to the server-server part, I have no strong opinions either
way.  I didn't suggest something LDAP-related because of my lack of LDAP
knowledge.  If someone wants to specify this in terms of LDAP, I have 
no problem.  If someone wants to do this as a separate server-sever protocol, 
I don't have a problem either.  If someone wants to do this as small extensions
to v4 (e.g. op to list a server's fs's, etc.), still no problem.  If none
of the above, then I do have a problem but not one I can do anything about,
so we'll just let that slide. 

With regard to the client-server part, the basic issue is that Brent's
approach is a ton of more work, and I'd prefer to limit the work involved,
particularly my own.  In addition to the every-nfs-client-has-to-have-an-
LDAP-client-as-well issue that Jim identified, a number of other things
become a whole lot more work.  The basic issue is that clients already 
have to deal with MOVED and getting a referral to a different location.
Does it make sense for them to have that facility but use it only rarely,
as Brent suggest, or instead use it for a wider range of circumstances,
in particular, for those in which the fs sought is at a different
location and was never actually served at its nominal address?  As far
as the actual work of writing the I-D (which is what concerns me right now)
there's the same issue.  The mechanism for a client to be directed to
another location is already defined.  The only thing that has to change 
is that the server should be encouraged to return fsid and well as fs_locations,
to deal with the case of crossing into the root of an absent fs.  This
would make server presentation of a global namespace feasible but it 
really should be done anyway, since even in the pure fs motion case (no
global namespace), the possiblity of crossing into an absent fs does
exist.

The other thing that makes this approach desirable is that, we can get
going on it, without waiting for v4.1.  The existing spec suggests the 
server will only return fs_locations but it desn't forbid returning 
other attributes (e.g. fsid) as well.  So here's a notice for Connectathon
participants.  I will have some servers set up so that you will cross
into an absent fs, and be redirected to another server.  Clients are
encouraged to interrogate fsid as well as fs_locations continue the
mount as if nothing is wrong, and nothing will be wrong.

When someone specifies the LDAP database to store this stuff, if that 
happens, I will modify my server to get the location data out of that,
thus implementing Jim's compromise.  Now all we need is a volunteer to
specify that LDAP, or the server-server protocol, or v4.1 fs discovery
extensions.  Any of the above work for me.  Volunteers?

-----Original Message-----
From: Jim Rees [mailto:[email-masked]]
Sent: Tuesday, December 09, 2003 7:24 PM
To: [email-masked]
Subject: Re: [nfsv4] Global namespace for v4.1? 

While I agree we shouldn't be inventing a new name service or database, I
worry that if NFSv4 gets too big it will collapse under its own weight the
way DCE/DFS did.  I don't think we should require clients to have an LDAP
client to work in the global file system.

Maybe a compromise would be to have the servers do the LDAP query on behalf
of the client.

_______________________________________________
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: Brent Callaghan <[email-masked]>
Date: Wed, 10 Dec 2003 14:08:16 -0800

I'm not singling out LDAP as the solution here, I'm suggesting
a nameservice might be a better model than one based on
server-server discovery.  As the number of servers increases,
the overheads in maintaining consistency and in administering
the database can quickly become unmanageable.  If we NFSers don't
want to depend on some existing nameservice and decide to invent
our own, that's fine too as long as we can justify the effort.

I'm not convinced that having a client participate directly in
namespace queries necessarily bloats the client.  Most
existing NFS clients already have built-in nameservice libraries,
whether they be Active Directory, DNS or LDAP, i.e. shared code
that's there whether we use it or not.

An argument for using existing, nameservices is that
they're built, tested, integrated and deployed.  Sysadmins
already have experience maintaining them.  Books are written
about them.  If an NFS namespace is to be administered differently;
to have its own authentication, authorization and admin tools
separate from other network services, then we need a pretty strong
argument for doing so.

	Brent