-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 25.09.2015 um 14:04 schrieb Vincent Lefevre: > On 2015-09-25 10:11:10 +0200, Peter Ludikovsky wrote: >> My guess is: Due to the rather large wsize/rsize, the clients >> create a rather large attribute cache. As a result, when you cat >> a file on the second machine it updates the atime in the cache, >> but doesn't yet transfer that information to the server. When you >> do the mv on the first machine, the client tries to get the >> current attributes on the files involved, which prompts the >> server to wait until the second client runs into some kind of >> timeout and updates the attributes. Only then is the second file >> "unlocked" to be overwritten. >> >> Further proof of that: when setting noatime as a mount option, >> instead of noac, there's also no delay on the mv. > > Thanks for the explanations. But the second client, though it > doesn't update the attributes immediately, seems to do it quickly > when asked by the server, otherwise the problem would also be > visible on Debian 7 machines. I think that on Debian 8, when the > rename cannot be done immediately, the client retries after 15 > seconds instead of retrying earlier. > > Is this related to the following patch? > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8478eaa16e701ecfe054b62ec764bc1291b79e19 > > Can't say if it's related. I have, however, managed to capture the related network traffic (see attachments). 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. Maybe attach that information to your bug report as a point for investigation. Regards /peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWCQizAAoJEM+6Ng5pbtyZxBUQAIp/OIHN4SM1N6DnS1GjN31Q 8i0eDFw3PNd/LoFBuQ8CUPK7U1ts8II2z0hBqCSFVj8VGGnxOVgkqYPEh2+Ovz4G 1SkeDmlo79POIwfXIhL8ORG/0svr2bbZ81L4ciFAQyF2xiRLq8Y+fNTgS5qNAjm2 xSFwnno7rXyKkT/U1oufjoCD65u263UpBCYgDeNs/pgbay+q3CEmYJOerd10cue7 fkgzysdRTYKQ9G9LqPsWPspMo+TMxzr415ln0bYcBmN/R0mQx4+lPzZsacSX4Hjh FO5y8j0xyJKUE9BS3dCDW7me9SMQl2fbCoS9eDTs5LocwnvhggVVbtVc1iAHL8te S06Fq8c2Pj5WNQlCP1cY42drJnqYOZdTirk2aAGAdklbRP1CBAvecld2r0vdAHFv 2tvSeyIYNVR5eGDT4tbpx94Dzy/MOM66d1Cxlu5lBk/pPOw1/gHwgxCIeHAXXV1d 5i1OYenFN988JQbr8kpyBwBVBuCK4IiGnOkZRECIdTS1VV6YzlpMH8LeRvKs8OiO t09O8LBoHvA9Zgy7Fz8c3mDlHhcRqJXRH7ArspMM519eFaXaxIzA0o1vQfHUzDB/ yPfVsnX0oCRF9VwfpIMOCg0RJBb/XZB3Iiotou+Uj8QOrcyY0Hw3NBOy1kQjtvUh bGysI2qLKAcggJ3P7k4n =3edq -----END PGP SIGNATURE-----
nfs_deb7.pcap
Description: Binary data
nfs_deb8.pcap
Description: Binary data
