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 _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs