Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8
Peter Ludikovsky wrote:
> Am 28.09.2015 um 18:59 schrieb Mike Kupfer:
> > In the deb7 trace, the other client is .4, not .3. It does not get
> > a delegation when it opens file2 (see packet 39), so the server
> > can process the RENAME immediately.
> Hang on, the two traces haven't been made at the same time, but rather
> separate. As in:
>
> * mount the share on 2 machines
> * create the files on one
> * cat it on the other
> * time mv again on the first
> * umount the share
Okay, but I don't understand why you mention that. In the deb7 trace,
the "other" client is not granted a delegation. In the deb8 trace, the
"other" client *is* granted a delegation. And it's almost certainly the
presence of this delegation that causes the server to stall the RENAME
request.
I looked at the traces some more. In the deb7 trace, the open of file2
by the .4 client is followed by an OPEN_CONFIRM handshake. This means
this is the first open that the .4 client is doing using that particular
open_owner (one of the state objects that NFSv4 introduced). The
callback information in the SETCLIENTID call (packet 34) looks sane, so
I think this is why the server did not grant a delegation in the deb7
trace case. That is, subsequent OPEN requests from the .4 client might
be granted delegations. (I say "might" because the server is free to
use various heuristics in deciding when to grant a delegation, and I
don't know what logic the Linux v4 server uses.)
I think it would be best to see packet traces from Vincent, if that's
possible. (The trace should include traffic between the server and both
clients.) I can think of a couple possible reasons why his Deb7 client
behaves better than the Deb8 clients, and having traces from his rig
would reduce the guesswork.
mike
Reply to: