Re: [nfsv4] more re: NFS4ERR_EXPIRED

spencer.shepler@sun.com

Message-Id: <B667A8BA-8E48-11D8-9D15-000A95DBCB70@sun.com>
From: Spencer Shepler <spencer.shepler@sun.com>
Subject: Re: [nfsv4] more re: NFS4ERR_EXPIRED
Date: Wed, 14 Apr 2004 14:19:55 -0500

Yes.  This seems to be a good idea.

On Apr 14, 2004, at 7:16 AM, Talpey, Thomas wrote:

> Thanks, all good points. Probably we should undertake an
>  informational "NFSv4 Client Best Practices" document, using
>  the knowledge we're amassing.
>
> Let's consider this for discussion at the upcoming Bakeathon.
>  I'll try to put together some ideas.
>
> Tom.
>
> At 02:10 AM 4/14/2004, Spencer Shepler wrote:
> >
>  >
>  >On Apr 13, 2004, at 12:27 PM, Talpey, Thomas wrote:
>  >
>  >
>  >Can someone clarify for me what recovery the client can/should
> >
>  >perform in the various cases we're describing? Do I read Dave
> >
>  >saying that EXPIRED might cause the client to invoke mass
> >
>  >recovery on all its stateids? This would be a pretty big incentive
> >
>  >to be careful with it!
> >
>  >
>  >The recovery path the client chooses is its own. Nothing is
> >
>  >prescribed in the RFC but one would likely expect that a reasonable
> >
>  >client may attempt to reopen files for which it held state at the
> >
>  >time of EXPIRED. I don't remember specifically if there is suggestion
> >
>  >of how the client may make a reasonable choice about when to
> >
>  >reopen a file.
>  >
>  >
>  >Things to consider from the client's perspective are things like:
>  >
>  >were file locks ever held for the file, was the file ever modified by
> >
>  >the client, a delegation was held but no active opens by applications
> >
>  >were present at the client, etc. Some clients may choose to be more
> >
>  >aggressive about their recovery patterns to deal with servers that
> >
>  >do not offer a grace period and will therefore respond to client
> >
>  >attempting to open files with CLAIM_PREVIOUS with the NO_GRACE
> >
>  >error. The reason I mention that here, even though it is a
> >
>  >different scenario, is that it is similar to the case that a client's
> >
>  >lease has expired.
> >
>  >
>  >The server should attempt to do its best to avoid returning EXPIRED
> >
>  >but it can not guarantee to do so.
> >
>  >
>  >
>  >I agree we should be much more explicit about CB_PATH_DOWN
>  >
>  >in the doc. There are only two sentences on it in RFC3530, both
> >
>  >referring to the server's responsibility. In fact, since the server
> >
>  >is required to renew leases after returning this, it would seem
> >
>  >to be more of a buying-time thing than an error.
> >
>  >
>  >A renewal of a lease does not guarantee that the server will
> >
>  >still not choose to revoke a delegation. It is not required to hold
> >
>  >the delegation forever; it should hold it for one lease period
> >
>  >and most likely it will be longer than that but it does need to
> >
>  >make forward progress and if the client is being stubborn about
> >
>  >returning a delegation (not making forward progress in the form
> >
>  >of flushing modified data for example) then it can revoke the
> >
>  >delegation and move on.
> >
>  >
>  >Spencer

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4