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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux