Re: [nfsv4] [FedFS] Multiple FSL resolution

Nico, what do you mean "resolving" a junction?  I'd expect that the
server consults the listed NSDB, looks up the entry for the FSN, gets
the list of FSLs, and passes some/most/all of them to the FS client.
The file server shouldn't have to further resolve the FSLs, nor should
it have to consult more than one NSDB for the list of FSLs.  Would this
be incorrect?

Or are you speaking of resolving multiple junctions for multiple queries
from FS clients?

		Craig

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] 
Sent: Monday, December 14, 2009 11:44 AM
To: Everhart, Craig
Cc: nfsv4@ietf.org; stacey_chris@emc.com
Subject: Re: [nfsv4] [FedFS] Multiple FSL resolution

On Thu, Dec 10, 2009 at 11:05:23AM -0500, Everhart, Craig wrote:
> As a quick shot, I believe that section 3.2, step 5, is in error, at
> least for the case of NFSv4{,.1}, which is the domain of discourse
here.
> All the FSL's for a given FSN should be converted and sent to the file
> server client, and the client can choose among them.
> 
> There are possible opportunities for introduction of policy-controlled
> behavior if there are more FSL's than a given server can convert or
than
> it can communicate to the file server client, but the idea is that the
> file servers take all locations from the NSDB and present them all to
> the client for its choice.

Indeed, you might not want the server to take too long resolving a
junction.  So if there's 10 FSLs the server might return as many as it
can resolve in, say, 10 seconds.

An implementation guideline should be included encouraging server
implementors to make junction resolution as parallel as possible.

Nico
-- 
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4