Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #158402

Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8

From Mike Kupfer <m.kupfer@acm.org>
Newsgroups linux.debian.user
Subject Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8
Date 2015-09-29 05:20 +0200
Message-ID <qdTCq-2zg-7@gated-at.bofh.it> (permalink)
References <qdKfL-5Rq-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8 Mike Kupfer <m.kupfer@acm.org> - 2015-09-28 19:10 +0200
  Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian  8 Peter Ludikovsky <peter@ludikovsky.name> - 2015-09-28 19:20 +0200
    Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8 Mike Kupfer <m.kupfer@acm.org> - 2015-09-29 05:20 +0200
      Re: NFS rename sometimes hangs for 15 seconds after upgrade to  Debian 8 Vincent Lefevre <vincent@vinc17.net> - 2015-10-01 14:00 +0200
        Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8 Mike Kupfer <m.kupfer@acm.org> - 2015-10-01 19:40 +0200
        Re: NFS rename sometimes hangs for 15 seconds after upgrade to  Debian 8 Stephan Seitz <stse+debian@fsing.rootsland.net> - 2015-10-01 20:00 +0200
          Re: NFS rename sometimes hangs for 15 seconds after upgrade to  Debian 8 Vincent Lefevre <vincent@vinc17.net> - 2015-10-02 13:20 +0200

csiph-web