Re: Linux NFSv4 client uses returned delegation in subsequent READ resulting in hang (BAD_STATEID)

["Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx>]

On Mon, 2012-07-02 at 17:19 -0400, Chuck Lever 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?

Yes. Is there a preamble to that, or did the client really try to
delegreturn immediately upon receiving a delegation?

-- 
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�����٥