Re: [PATCH pynfs 02/17] 4.1 server: service RECLAIM_COMPLETE operations

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Jun 05, 2014 at 09:34:14AM -0400, Weston Andros Adamson wrote:
> On second thought, I’m just going to drop this patch.
> 
> I only added it to avoid a NFS4ERR_NOTSUPP when connecting the file layout
> MDS to pynfs DSes, but it is harmless and outside the scope of what I’m doing.
> 
> Not worth that can of worms.

The MDS shouldn't really have to handle NOTSUPP on RECLAIM_COMPLETE
(even if yours currently happens to).  I think your no-op patch as it is
would be better than nothing.

--b.

> 
> -dros
> 
> 
> 
> On Jun 5, 2014, at 9:18 AM, Weston Andros Adamson <dros@primarydata.com> wrote:
> 
> > 
> > On Jun 5, 2014, at 9:06 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > 
> >> On Thu, Jun 05, 2014 at 08:58:01AM -0400, Weston Andros Adamson wrote:
> >>> Are you saying that the pynfs server supports state recovery? This has not
> >>> been my experience. I’ll double check.
> >> 
> >> If you don't support state recovery, then I think the minimal correct
> >> behavior would be to have no grace period at all: return NO_GRACE on
> >> *every* reclaim operation and GRACE only on non-reclaims not preceded by
> >> a global (one_fs == FALSE) RECLAIM_COMPLETE for that client.
> >> 
> >> All this does is catch misbehaving clients, and maybe that's not a
> >> priority.  But it's easy enough to implement.
> > 
> > Yeah, that sounds good.
> > 
> > -dros
> > 
> >> 
> >> —b.
> >> 
> >>> -dros
> >>> 
> >>> 
> >>> 
> >>> On Jun 5, 2014, at 8:22 AM, Trond Myklebust <trondmy@gmail.com> wrote:
> >>> 
> >>>> On Wed, Jun 4, 2014 at 10:29 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >>>>> On Wed, Jun 04, 2014 at 05:01:50PM -0400, Weston Andros Adamson wrote:
> >>>>>> Just return ok!
> >>>>> 
> >>>>> Technically it should record whether or not the reclaim_complete has
> >>>>> happened and return a GRACE error on any non-reclaim open performed
> >>>>> before the reclaim_complete--but for your purposes you may not care...
> >>>>> 
> >>>> 
> >>>> ...and a NOGRACE error on any reclaim opens performed by that client
> >>>> after the reclaim_complete?
> >>>> 
> >>>>> --b.
> >>>>> 
> >>>>>> 
> >>>>>> Signed-off-by: Weston Andros Adamson <dros@primarydata.com>
> >>>>>> ---
> >>>>>> nfs4.1/nfs4server.py | 3 +++
> >>>>>> 1 file changed, 3 insertions(+)
> >>>>>> 
> >>>>>> diff --git a/nfs4.1/nfs4server.py b/nfs4.1/nfs4server.py
> >>>>>> index 65fb9af..3607dc0 100755
> >>>>>> --- a/nfs4.1/nfs4server.py
> >>>>>> +++ b/nfs4.1/nfs4server.py
> >>>>>> @@ -1809,6 +1809,9 @@ class NFS4Server(rpc.Server):
> >>>>>>       with find_state(env, arg.deleg_stateid, allow_0=False) as state:
> >>>>>>           state.delegreturn()
> >>>>>>       return encode_status(NFS4_OK)
> >>>>>> +
> >>>>>> +    def op_reclaim_complete(self, arg, env):
> >>>>>> +        return encode_status(NFS4_OK)
> >>>>>> 
> >>>>>>   def op_getdevicelist(self, arg, env): # STUB
> >>>>>>       check_session(env)
> >>>>>> --
> >>>>>> 1.8.5.2 (Apple Git-48)
> >>>>>> 
> >>>>> --
> >>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>>>> the body of a message to majordomo@vger.kernel.org
> >>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>> 
> > 
>