Subject: [nfsv4] NFS4ERR_REC LAIM_BAD

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 28 May 2009 12:57:35 -0400

Draft-29 has the following:

> 15.1.9.4.  NFS4ERR_RECLAIM_BAD (Error Code 10034)
>
>    A reclaim attempted by the client does not match the server's state
>    consistency checks and has been rejected therefore as invalid.

It's not very clear what state consistency check a server may (or must)
enforce.  If I recall the original discussion about this error is that
the intention was to cover any case in which the server is able
(reliably) to determine that a reclaim request could not be valid.  The
was as opposed to NFS4ERR_RECLAIM_CONFLICT which was returned when the
server was able to determine to that someone had made an invalid reclaim
request although it is not necessarily the case that this one is
invalid.

More succinctly:

     RECLAIM_CONFLICT = "Somebody is lying"

     RECLAIM_BAD = "You're lying"

Different servers might maintain different sets of information that
enable them to detect an erring client under different circumstances, or
not at all.  For example, a server might have persistent information
about which filesystems potentially have locks present, enabling it to
determine that a reclaim on some other fs could not possibly be valid.

Other servers might do other things of nothing at all in this area.
Clustered systems are likely to have a wide range of information that
might allow them to determine that a particular reclaim is invalid.

So my suggestion for clarifying this is to have:

> 15.1.9.4.  NFS4ERR_RECLAIM_BAD (Error Code 10034)
>
>    The server has determined that a reclaim attempted by the client 
>    is not valid, i.e. the lock specified as being reclaimed could
>    possibly existed before the server reboot.  A server is not 
>    obliged to make this determination and will typically rely on the
>    client to only reclaim locks that it was granted.  However, when a
>    server does have reliable information to enable it make this 
>    determination, this error indicates that the reclaim has bee
rejected 
>    as invalid.  This is as opposed to NFS4ERR_RECLAIM_CONFLICT where 
>    the server can only determine that there has been an invalid
reclaim  
>    but has no way of determining which request is responsible.

RFC3530 has:
 
>   NFS4ERR_RECLAIM_BAD   The reclaim provided by the client does not
>                         match any of the server's state consistency
>                         checks and is bad.

which might be clarified similarly in rfc3530bis.

Comments?

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 28 May 2009 14:17:05 -0400

>      RECLAIM_BAD = "You're lying"

Quibble: In a multiple-reboot-with-network-partition case, a correctly
functioning client can attempt to reclaim something that the server
knows it can't have held.  (Unless I'm missing something?)  So this
isn't necessarily the client's fault, exactly.

> >    possibly existed before the server reboot.  A server is not 

Nit: you meant to have a "not" in there.

--b.

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 29 May 2009 11:27:16 -0400

> Quibble: In a multiple-reboot-with-network-partition case, a 
> correctly functioning client can attempt to reclaim something 
> that the server knows it can't have held.  (Unless I'm missing 
> something?)  So this isn't necessarily the client's fault, 
> exactly. 

I think you are speaking of what the specs refer to as "edge
conditions".  If the client attempts recaims in those situations, they
may indeed be incorect without the client lying.  However, the spec says
that the server in those conditions is supposed to return
NFS4ERR_NO_GRACE.  If he doesn't do that, then he is supposed to have
verified that none of the conditions that would allow a properly
functioning client to try to reclaim locks he doesn't own, could be
occurring.

Yes, thanks.

>    not possibly have existed before the server reboot.  A server 
>    is not obliged to make this determination and will typically rely 
>    on the client to only reclaim locks that it was granted.  However, 
>    when a server does have reliable information to enable it make  
>    this determination, this error indicates that the reclaim has 
>    been rejected as invalid.  This is as opposed to the error
>    NFS4ERR_RECLAIM_CONFLICT where the server can only determine that 
>    there has been an invalid reclaim but has no way of determining 
>    which request is thre invalid one.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Thursday, May 28, 2009 2:17 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] NFS4ERR_REC LAIM_BAD

On Thu, May 28, 2009 at 12:57:35PM -0400, Noveck, Dave wrote:
> It's not very clear what state consistency check a server may (or 
> must) enforce.  If I recall the original discussion about this error 
> is that the intention was to cover any case in which the server is 
> able
> (reliably) to determine that a reclaim request could not be valid.  
> The was as opposed to NFS4ERR_RECLAIM_CONFLICT which was returned when

> the server was able to determine to that someone had made an invalid 
> reclaim request although it is not necessarily the case that this one 
> is invalid.
> 
> More succinctly:
> 

> enable them to detect an erring client under different circumstances, 
> or not at all.  For example, a server might have persistent 
> information about which filesystems potentially have locks present, 
> enabling it to determine that a reclaim on some other fs could not
possibly be valid.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 29 May 2009 12:08:18 -0400

On Fri, May 29, 2009 at 11:27:16AM -0400, Noveck, Dave wrote:
> NFS4ERR_NO_GRACE.

Whoops, you're right, I'd missed that language about the use of
NO_GRACE.

--b.

> If he doesn't do that, then he is supposed to have