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 Linux client does not expect a delegation when it sends
CLAIM_DELEGATE_CUR requests, and ends up getting confused; it reinstates
the delegation. This is an issue that we will not fix on the client,
since it is a server bug...
Cheers
Trond
--
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�����٥
