Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #158386 > unrolled thread
| Started by | Mike Kupfer <m.kupfer@acm.org> |
|---|---|
| First post | 2015-09-28 19:10 +0200 |
| Last post | 2015-10-02 13:20 +0200 |
| Articles | 7 — 4 participants |
Back to article view | Back to linux.debian.user
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
| From | Mike Kupfer <m.kupfer@acm.org> |
|---|---|
| Date | 2015-09-28 19:10 +0200 |
| Subject | Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8 |
| Message-ID | <qdK66-5Gg-9@gated-at.bofh.it> |
Peter Ludikovsky wrote: > The big difference happens at packets 58/54 (Deb7/Deb8). For Deb7, the > RENAME call is immediately answered by an NFS4_OK, whereas for Deb8 as > the client it's an NFS4ERR_DELAY. I haven't seen any reason on the > client communication that would explain that, however this is far > beyond my knowledge of the NFS internals. The DELAY response in the deb8 trace is likely so that the server can ask the .3 client to return its delegation, which it does at packets 56-57. (The .3 client obtained its delegation at packet 39 as part of the reply to the OPEN op.) 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. mike
[toc] | [next] | [standalone]
| From | Peter Ludikovsky <peter@ludikovsky.name> |
|---|---|
| Date | 2015-09-28 19:20 +0200 |
| Subject | Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8 |
| Message-ID | <qdKfL-5Rq-1@gated-at.bofh.it> |
| In reply to | #158386 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 28.09.2015 um 18:59 schrieb Mike Kupfer: > Peter Ludikovsky wrote: > >> The big difference happens at packets 58/54 (Deb7/Deb8). For >> Deb7, the RENAME call is immediately answered by an NFS4_OK, >> whereas for Deb8 as the client it's an NFS4ERR_DELAY. I haven't >> seen any reason on the client communication that would explain >> that, however this is far beyond my knowledge of the NFS >> internals. > > The DELAY response in the deb8 trace is likely so that the server > can ask the .3 client to return its delegation, which it does at > packets 56-57. (The .3 client obtained its delegation at packet 39 > as part of the reply to the OPEN op.) > > 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. > > mike > 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 However, the captures omit the mount/umount part, since that doesn't appear to affect the outcome. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWCXahAAoJEM+6Ng5pbtyZJ1IP/3QJi8sJPPfGvLBxwKK8h2lx ywnVGRzZhM90ILND6JjIBXmlgKEdGf6fHxdu9cjLDYri3CzfL/oM2T/X3CPmCn3s 23T8x2P6Yp3jGhR8HgxV/HWlUAt3wKpzfkYiQFGHVmjR78nEE61Do027p/Z2M31E nBy8yNUoINjY0RGfiHVm0zzU+CrPG/CVUmWNFTB+Z9xkz96svqdudttoa5HMEON+ QHzNYtyw2dsg9EI2VxxDe/Uv1MJz7CIy41cTsQCZYaQOhBw+ywExNRww6IZcDg4R QpLNv2Vo2NvQpuENQyqgEgx22opTuKbNLFoCN2DUDWPXhjRN1sqVuWgjWvX3+7X7 et3EqddZRZosjSOSI1sTMfWixQUIvimg9qnlovBh4qzZXmsyPUKC6852qhoHk/IN JyHggEff/u3TeMmJqnyHgI1Gys08kXyCql3DGMyhIii4xJ2bLK//JvyhuGe6JzOn Zo5UQt1nr+M5t0xwCKX0HvpnSbKhC04HDYxaTZ/DAgT9t3yOMFstM0vn8m0M4z2C W3ry8itJf5PP9bWCeI3XbgsZkwrcg57oK4VfXE3hGQjzZQ+Bkina1vLQcDRywcrx 7ENbUQH7QbzmheM/ezzw6Vz+AdRvWwus1CSJ0fqeBTdSU+lDGUKQpLVbtY1yQfvL XK5RL1TmemDp5VkrRDPT =+m/o -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | Mike Kupfer <m.kupfer@acm.org> |
|---|---|
| Date | 2015-09-29 05:20 +0200 |
| Message-ID | <qdTCq-2zg-7@gated-at.bofh.it> |
| In reply to | #158387 |
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
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2015-10-01 14:00 +0200 |
| Subject | Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8 |
| Message-ID | <qeKGL-383-23@gated-at.bofh.it> |
| In reply to | #158402 |
On 2015-09-28 20:12:50 -0700, Mike Kupfer wrote: > 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. Is there a way to get traces as a normal user? Otherwise I'll have to ask the sysadmin... -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Mike Kupfer <m.kupfer@acm.org> |
|---|---|
| Date | 2015-10-01 19:40 +0200 |
| Message-ID | <qePZM-2Ya-19@gated-at.bofh.it> |
| In reply to | #158502 |
Vincent Lefevre wrote: > Is there a way to get traces as a normal user? Not that I know of. mike
[toc] | [prev] | [next] | [standalone]
| From | Stephan Seitz <stse+debian@fsing.rootsland.net> |
|---|---|
| Date | 2015-10-01 20:00 +0200 |
| Subject | Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8 |
| Message-ID | <qeQj8-3kO-31@gated-at.bofh.it> |
| In reply to | #158502 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Oct 01, 2015 at 01:54:07PM +0200, Vincent Lefevre wrote: >Is there a way to get traces as a normal user? >Otherwise I'll have to ask the sysadmin... Yes. If you do a „dpkg-reconfigure wireshark-common” you’ll get ask if normal user should be allowed to trace. If you say yes then a new group called wireshark will be created. Everyone who is a member of this group can now use wireshark or tshark. This should work in Debian 7 and 8. Many greetings, Stephan -- | Stephan Seitz E-Mail: stse@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html |
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2015-10-02 13:20 +0200 |
| Subject | Re: NFS rename sometimes hangs for 15 seconds after upgrade to Debian 8 |
| Message-ID | <qf6xA-1JT-13@gated-at.bofh.it> |
| In reply to | #158510 |
On 2015-10-01 19:43:03 +0200, Stephan Seitz wrote: > On Thu, Oct 01, 2015 at 01:54:07PM +0200, Vincent Lefevre wrote: > >Is there a way to get traces as a normal user? > >Otherwise I'll have to ask the sysadmin... > > Yes. If you do a „dpkg-reconfigure wireshark-common” you’ll get ask > if normal user should be allowed to trace. If you say yes then a new > group called wireshark will be created. Everyone who is a member of > this group can now use wireshark or tshark. This doesn't help because a normal user can't do that, and even if the sysadmin adds a normal user to the wireshark group, this would allow this user to see the packets for the processes of the other users. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web