Re: [nfsv4] more re: NFS4ERR_EXPIRED

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Spencer Shepler (spencer.shepler@sun.com)
Date: 04/14/04-01:10:02 AM Z


Message-Id: <5DE7970C-8DDA-11D8-B69B-000A95DBCB70@sun.com>
From: Spencer Shepler <spencer.shepler@sun.com>
Subject: Re: [nfsv4] more re: NFS4ERR_EXPIRED
Date: Wed, 14 Apr 2004 01:10:02 -0500


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


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:25 AM Z CST