On Mon, 2012-07-02 at 22:50 +0100, Charles 'Boyo wrote:
> On Mon, Jul 2, 2012 at 10:19 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
> >
> > On Jul 2, 2012, at 5:13 PM, Myklebust, Trond wrote:
> >
> >> On Mon, 2012-07-02 at 16:35 -0400, Chuck Lever wrote:
> >>> On Jul 2, 2012, at 4:22 PM, Charles 'Boyo wrote:
> >>>
> >>>> On Mon, Jul 2, 2012 at 3:09 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
> >>>>>
> >>>>> Usually we see this behavior because of a race between an OPEN with delegation and a delegation recall. In this case, however, the client is actively returning a READ
> >>>>> delegation, then proceeding to use it anyway. I don't see the server's recall callback, though, and there are other indications that this trace is not complete. So it's hard
> >>>>> to be 100% confident.
> >>>>>
> >>>> The trace is not complete, it includes just enough information to
> >>>> explain the problem.
> >>>> However I can confirm the service did not send a recall callback, the
> >>>> client returned the delegation of its own "free will".
> >>>
> >>> The callback would come on a separate TCP connection. I can't think of a reason that a client would return a delegation by itself and then subsequently start to use it.
> >>
> >> I can: there are a number of servers out there that violate the spec by
> >> returning a delegation as part of an OPEN(CLAIM_DELEGATE_CUR). Usually
> >> those broken servers will send the exact same stateid as the delegation
> >> that is being returned.
> >
> > The OPEN in frame 7 is a CLAIM_NULL OPEN, isn't it?
> >
> The OPEN in this case is a CLAIM_NULL and I have re-examined my
> network dump, there was no call back from the server.
> So why would the client returns a delegation voluntarily and then re-use it?
>
> >>>> Is it possible is a scheduling issue of some sort, where the READ
> >>>> should have been sent ahead of the DELEGRETURN but somehow got mixed
> >>>> up?
>
> >>> Or possibly that the DELEGRETURN doesn't actually remove the delegation state ID until the server has replied, and the READ request was sent before the DELEGRETURN
> >>> reply arrived at the client.
>
> Indeed, the READ was issued after the DELEGRETURN but before the
> response to it. Is it possible to check if this is expected behavior?
That is expected behaviour. We don't serialise READ and DELEGRETURN.
What isn't expected behaviour is for the client to DELEGRETURN
immediately upon receiving the delegation. Nor is it expected that the
READ would fail to recover in an ordinary DELEGRETURN situation.
This is why I'm interested in seeing what happened before the OPEN.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
