Re: [nfsv4] [FedFS] Meeting Minutes, 11/5/2009

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

On Fri, Nov 06, 2009 at 09:08:15AM -0500, James Lentini wrote:
> On Thu, 5 Nov 2009, Nicolas Williams wrote:
> > If you can come up with a complete list of errors, then it's better to
> > have error codes for all of them.  You can always punt and say "go look
> > at logs" (logs are never localized).
> 
> Thank you for making us aware of that. Including a text field would be 
> in the "bells and whistles" category. If it would require a 
> significant increase in complexity, it probably isn't worth it.

I agree, it's bells and whistles.

> > A coarse error is a lot better than nothing.  But there's no reason that
> > we couldn't specify a finer-grained set of errors and let
> > implementations use them that can.  The errors I can think of:
> 
> We could add more error codes. They won't eliminate the need for an 
> administrator to diagnose the problem. 

Indeed, but it's very nice to go in to battle with a clue.

Looking at this from a user-friendliness p.o.v., where the user is a
sysadmin, but still a user, a human being, one who will curse our names
if we make life too hard for them...

...well, the implementation will have known what went wrong, so why not
tell the sysadmin?  Now, I grant you that when you have many layers it's
easy to lose track of specific errors and surrounding context, but just
because that's a common result doesn't mean this protocol should carve
that result into stone.

> >  - NSDB object not found
> 
> The FEDFS_ERR_NOFSN and FEDFS_ERR_NOFSL error codes in the update are 
> for this case.

OK.

> >  - NSDB object missing required attributes
> 
> Rob suggested the same thing below (see note about malformed response 
> error). That is on the list of error codes to add.

OK.

> > How long to delay?  Users will want to know.  Shouldn't NFSv4.1 have a
> > way to say "this is a junction, but I can't figure out where to refer
> > you to"??
> 
> This was a side discussion. The NFS GETATTR operation, which is used 
> to fetch the fs_locations or fs_locations_info data, may return the 
> error NFS4ERR_DELAY. We were discussing times when it would be 
> appropriate for the fileserver NFS4ERR_DELAY. Obviously, this isn't 
> part of FedFS. It has already been described in NFSv4.

I understand, and I think that's unfortunate.  The NFSv4 server could
distinguish a bit more and say "this is a junction, but I can't resolve
the referral for it".  Compare to "I may need to pull this from a
tape library, hold on a minute" -- clients might react differently.  Oh
well.

> > >   Craig suggested that the resolve parameter be a ternary instead of binary
> > >   value: 0 = don't resolve, 1 = resolve using cache value, and 2 = resolve 
> > >   using nsdb.
> > 
> > What cached value?
> 
> The fileserver may have cached FSL values. See Section 2.4.2 "Caching 
> of Fileset Locations" in 

Should we have a notion of FSN/FSL soft and _hard_ TTLs?  Soft TTL
expiration -> attempt to re-resolve.  Hard TTL expiration -> if can't
resolve, then the junction returns an error.

Nico
--