[fedfs-utils] [autofs] [PATCH] FedFS file system client support

[Chuck Lever]

On May 30, 2011, at 12:15 AM, Ian Kent wrote:

> On Thu, 2011-05-26 at 12:39 -0400, Chuck Lever wrote:
>> Hi-
>> 
>> The next release of fedfs-utils will provide all necessary components
>> for a Linux NFS client to participate in a FedFS domain as a file
>> system client.  This new utility is intended to be a part of the
>> upcoming release.
>> 
>> I'm interested in comments on this approach.  Ian had suggested a new
>> lookup module, but a program map looked simpler to prototype and has
>> the great advantage of no dependencies between fedfs-utils and autofs.
>> If program maps have some nasty problem that require the use of a
>> lookup module, we can take that next step.
> 
> The only difficulty with using a program map is that to use it you need
> to know the name of the of the <key> (aka. /nfs4/<key>) since, at the
> moment, autofs can't enumerate program map keys.

If I understand your comment correctly, the problem is how the client discovers FedFS domain names to use as keys.

As I understand it, FedFS does not currently have a mechanism for clients to discover FedFS domain names, like, say, AFS did with CellServDB.

Also, FedFS file system clients don't belong to a particular domain, so they don't have any idea what might be their "local" domain.  Any client can access any domain; security is provided by the underlying file system protocols.  The domains are just a way to organize the name spaces, without any regard to security administrative domains.

Thus, right now users and applications have to know a priori the whole pathname (or, Globally Useful Name, in FedFS parlance) in order to access a file resource via FedFS.

Are you suggesting there is a better design we could adopt that might prepare FedFS for a time when there is a mechanism for discovering FedFS domain names?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com