Here are the traces done at my lab. I recall the test between
hosts A and B (see the prompt):
A% echo foo > file1
A% cp file1 file2
B% cat file2
A% time mv file1 file2
Test 1:
A = Debian 8 - debian-8_20.pcap (15s delay between the 2 RENAME)
B = Debian 7 - debian-7_20.pcap
Test 2:
A = Debia
According to Peter Ludikovsky in the debian-user list:
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
>
Mount information:
filer.lip.ens-lyon.fr:/export/home/vlefevre on /home/vlefevre type nfs4
(rw,nosuid,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=140.77.14.11,local_lock=none,addr=140.77.14.5)
--
Vincent Lefèvre - Web: <
On 2015-09-23 13:42:25 +0200, Vincent Lefevre wrote:
> I can simply reproduce the problem by reading the target on some
> machine, then moving a file to the target on another (Debian 8)
> machine. For instance:
>
> cassis% echo foo > file1
> cassis% cp file1 file2
>
> fraise% cat file2
> foo
>
>
I can simply reproduce the problem by reading the target on some
machine, then moving a file to the target on another (Debian 8)
machine. For instance:
cassis% echo foo > file1
cassis% cp file1 file2
fraise% cat file2
foo
then back on cassis (a Debian 8 machine):
cassis% time mv file1 file2
mv
Package: src:linux
Version: 3.16.7-ckt11-1+deb8u4
Severity: important
At my lab, with NFS accounts, some machines have been reinstalled
with Debian 8. and on these machines, NFS rename sometimes hangs
for 15 seconds (the NFS server isn't particularly loaded), while
this problem never occurs under
6 matches
Mail list logo
