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

brent@eng.sun.com

Message-ID: <3FD79950.9030908@eng.sun.com>
From: Brent Callaghan <brent@eng.sun.com>
Subject: Re: [nfsv4] Global namespace for v4.1?
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

Noveck, Dave wrote:
> 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:rees@umich.edu]
> Sent: Tuesday, December 09, 2003 7:24 PM
> To: nfsv4@ietf.org
> 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
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> 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