On Thu, 2012-07-05 at 20:23 +0100, Charles 'Boyo wrote:
> >> 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.
> >>
> >
> > Attached is a minimally redacted trace which contains all the NFS
> > calls and responses before and through this particular DELEGRETURN
> > (frame 6084).
> > I am unable to provide the full packet capture due to the sensitivity
> > of the data contained therein.
>
> Trond, did the attached trace confirm the issue as suspected?
>
> Charles
No. What is happening is that the client does an OPEN of file
"account.info". It then closes the file and for some reason that I don't
yet understand, it decides to return the delegation.
Then the application does another OPEN, which races with the delegation
return. Because of the race, the server returns the same delegation as
it did in the first open call. The client (which has now forgotten about
the original open) sees what it thinks is a new delegation, and so it
adopts it.
So this explains why the READs end up trying to use a returned
delegation. What remains to be explained is:
a) Why did the client return the delegation in the first place? Is it in
some extreme memory pressure situation, or does it perhaps have some
funky setting for /proc/sys/vm/vfs_cache_pressure?
b) Why doesn't the recovery scenario kick in and do the right thing?
--
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�����٥
