Subject: [nfsv4] Follow up on close() during Grace.

From: Robert Gordon <[email-masked]>
Date: Mon, 29 Nov 2004 12:24:14 -0800

I've been catching up on the WG-Mail and noticed that the
following thread seemed to "wither" from a WG-Mail perspective.

Was there a conclusion off-list ?

> On Jul 25, 2004, at 9:49 AM, Noveck, Dave wrote:
>
>> Brian, Spencer.  Does this mean we can't mention DONE_RECOVERY in San 
>> Diego?
>> I have this vision of us sitting in the meeting with laptops and 
>> sending
>> email to the working group back and forth but the words DONE_RECOVERY 
>> never
>> passing our lips :-)
>
> I will assign 10-15 minutes for you to present the issues and make 
> sugguestions
> of how to address it and where it best fits in our current or future
> minor versioning proposals.
>
> Spencer

and this was Mike's Last comment on the subject:

> 	From: 	  [email-masked]
> 	Subject: 	RE: [nfsv4] more re: close during grace
> 	Date: 	July 26, 2004 1:26:46 PM PDT
> 	To: 	  [email-masked]
>
> > Note also that when we have such a client [that fails to issue
> > DONE_RECOVERY], the fact is marked in
> > stable storage so that if we (the server) reboot, when that
> > client tries to reclaim he will get NO_GRACE even if this time
> > he is within the grace period.
>
> I think that rather than NO_GRACE, there should be
> a new error code, for this situation in the interest of
> clarity.
>
> In fact at least three new error codes would be clearer:
>
> 1. For the case when a client is reclaiming stuff during
>    a server instance, and then sends a steady state
>    operation to increase (or if the server insists,
>    reduce) state.
>
> 	NFS4ERR_FINISH_YOUR_RECOVERY
>
>    The client must respond with DONE_RECOVERY to get out of
>    this situation.
>
> 2. For the case when the client is reclaiming stuff,
>    but the server knows that it rebooted at least once
>    with the client failing to issue DONE_RECOVERY (edge
>    condition 2 in section 8.6.3, or the modified
>    edge condition Dave came up with that I described
>    last week); and the server cannot determine if a
>    conflicting lock was granted.
>
>        NFS4ERR_MISSED_RECOVERY
>
>    At minimum, the cliebt must respond with DONE_RECOVERY
>    to get out of this situation. In addition, he is
>    advised to acquires the lock state he needs without
>    the reclaim flags to the affected operations, then
>    do a GETATTR "change" operatioa, and then compare
>    the attribute with what was cached. This is so the client
>    can determine if another client changed things
>    from underneath him.
>
> 3. As 2, but the server knows a conflicting lock
>    was granted.
>
>       NFS4ERR_CONFLICTED_STATE
> >
> > -----Original Message-----
> > From: Nicolas Williams [mailto:[email-masked]]
> > Sent: Monday, July 26, 2004 2:38 PM
> > To: Spencer Shepler
> > Cc: Noveck, Dave; [email-masked]; [email-masked]
> > Subject: Re: [nfsv4] more re: close during grace
> >
> >
> > One issue with DONE_RECOVERING: what if it never comes, or takes too
> > long to come?  At some point one of the clients must lose...  That 
> may
> > require administrative action on the client to recover, but
> > it's better
> > than DoSing the server.
>
> I'm assuming most clients will return errors to applications,
> and/or send SIGLOST.
>

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4