-----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-----
