Subject: Re: [nfsv4] more re: NFS4ERR_EXPIRED

From: "Talpey, Thomas" <[email-masked]>
Date: Wed, 14 Apr 2004 05:16:23 -0700

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

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 14 Apr 2004 14:19:55 -0500

Yes.  This seems to be a good idea.