Message ID | 1401915726-29092-3-git-send-email-dros@primarydata.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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... --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
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 -- 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
Are you saying that the pynfs server supports state recovery? This has not been my experience. I’ll double check. -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 -- 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
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. --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 > -- 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
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 >> -- 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
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. -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 >>> > -- 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
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 > >>> > > > -- 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
Well, it works fine without it - the pynfs MDS just ignores the NOTSUPP! If you really want it I can submit it later, but it’s unneeded and unrelated to the goals of this patchset. -dros On Jun 5, 2014, at 9:41 AM, J. Bruce Fields <bfields@fieldses.org> wrote: > 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 >>>>> >>> >> -- 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
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)
Just return ok! Signed-off-by: Weston Andros Adamson <dros@primarydata.com> --- nfs4.1/nfs4server.py | 3 +++ 1 file changed, 3 insertions(+)