On Jul 2, 2012, at 5:48 PM, Myklebust, Trond wrote: > 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? Charles, we would like to see an un-redacted trace, if you have one. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
