Re: [nfsv4] FedFS Meeting Minutes, 10/22/2009

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Fri, Oct 23, 2009 at 10:51:09AM -0400, James Lentini wrote:
> On Thu, 22 Oct 2009, Nicolas Williams wrote:
> > Speaking of errors, the server should try to resolve FSNs immediately
> > upon junction creation, 
> 
> That seems like a reasonable thing to recommend.

I'd rather REQUIRE it: the server will have to resolve the FSNs
eventually, so why not _now_?  Though I'd allow an option in the RPC to
skip this (in case you're building a namespace at a time when not all
services are reachable).

> > and there should be a procedure for getting a list of FSNs/FSLs that 
> > have been unresolvable "lately", as well as FSN/FSL resolution error 
> > counts/stats.  The recent error list/stats part seems particularly 
> > useful: there must be a way to diagnose such failures, and without a 
> > protocol for it the diagnostic procedures will be vendor-specific.
> 
> Good idea. What should a stat operation return? It seems that the 
> total # of installed junctions, their FSNs, their locations, and the 
> number of successful + failed resolutions for each would be useful.

Counters would certainly be nice (plus a way to reset them?).  I was
also thinking of resolution failure rate and referral failure rates
(resolution failed and not in cache) running averages (over hours, days,
weeks?), so you can have an idea of how likely it is that a server's
clients are noticing errors.

Nico
--