NFS, client to server, time too large
distribution: SuSE 9.0 on both machines

Status:
NFS server:
name ijsbeer
IP ..130.
Shared dir: /test

NFS Client
IP ..150.
Dir /ijsbeer/test
On client mounting at startup
192.168.1.130:/test /ijsbeer/test nfs defaults 0 0

test:
control from client
(data from server to client)
transport large file (70KB) from ijsbeer /test to client /ijsbeer/tmp
result: time = miliseconds

(data from client to server)
transport small file (1.5 KB) from tmp to /ijsbeer/test
result: time = minutes.

Even a larger file transfport cost more then a hour.
That is not good, I know. Also, in short terms:
From server to client = ok
From client to server = more then worst.
Who has an answer, or like to help.

Henk
NL

have you checked dmesg output (as well as other logs) on both client and server? maybe something is blocking the transfers at UDP level. you also might benefit from settngs the block size when you mount:
for example.

Hello Chris

The change in fstab > hard,rsize=8192,wsize=8192 <
doen't make any difference. The same problem.
My firewall is switched off.
First you see a tcpdump of the server
Then the one of the client.
A big difference. Is that correct ? Or what is the failure ?
And where can I find and correct it.
(please be patient, I'm a newbee)

part of tcpdump server:
11:20:10.922748 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1797:948@7400)
11:20:13.722799 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1798:948@7400)
11;20:13.822611 arp who-has ijsbeer.ter-elst tell Lindhoos.ter-elst
11:20:13.822649 arp reply ijsbeer.ter-elstis-at 0:e:a6:c2:36:f8
11:20:19.322880 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1799:948@7400)
11:20:20.022894 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1800:948@7400)
11:20:21.422925 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1801:948@7400)
11:20:24.222969 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1803:948@7400)
11:20:29.823052 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1804:948@7400)
11:20:30.523070 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1805:948@7400)
11:20:31.923092 Lindhoos.ter-elst > ijsbeer.ter-elst:udp (frag 1806:948@7400)

part of tcpdump client:
11:20:11.463482 Lindhoos.ter-elst.1227992992 > ijsbeer.ter-elst.nfs: 1472 write [|nfs] (frag 1796:1480@0+)
11:20:12.863390 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1797:948@7400)
11:20:12.863417 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1797:1480@5920+)
11:20:12.863430 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1797:1480@4440+)
11:20:12.863443 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1797:1480@2960+)
11:20:12.863457 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1797:1480@1480+)
11:20:12.863473 Lindhoos.ter-elst.1227992992 > ijsbeer.ter-elst.nfs: 1472 write [|nfs] (frag 1797:1480@0+)
11:20:15.663393 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1798:948@7400)
11:20:15.663424 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1798:1480@5920+)
11:20:15.663440 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1798:1480@4440+)
11:20:15.663453 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1798:1480@2960+)
11:20:15.663466 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1798:1480@1480+)
11:20:15.663483 Lindhoos.ter-elst.1227992992 > ijsbeer.ter-elst.nfs: 1472 write [|nfs] (frag 1798:1480@0+)
11:20:15.763353 arp who-has ijsbeer.ter-elst tell Lindhoos.ter-elst
11:20:15.763479 arp reply ijsbeer.ter-elst is-at 0:e:a6:c2:36:f8
11:20:21.263383 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1799:948@7400)
11:20:21.263411 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1799:1480@5920+)
11:20:21.263426 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1799:1480@4440+)
11:20:21.263441 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1799:1480@2960+)
11:20:21.263454 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1799:1480@1480+)
11:20:21.263470 Lindhoos.ter-elst.1227992992 > ijsbeer.ter-elst.nfs: 1472 write [|nfs] (frag 1799:1480@0+)
11:20:21.963387 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1800:948@7400)
11:20:21.963414 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1800:1480@5920+)
11:20:21.963429 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1800:1480@4440+)
11:20:21.963444 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1800:1480@2960+)
11:20:21.963458 Lindhoos.ter-elst > ijsbeer.ter-elst: udp (frag 1800:1480@1480+)
11:20:21.963474 Lindhoos.ter-elst.1227992992 > ijsbeer.ter-elst.nfs: 1472 write [|nfs] (frag 1800:1480@0+)

there is a smal time difference between the software clock Forget that.

I have seen this caused by UDP fragmentation. For me, this happened in our Load balancer hardware. The only way I've found to resolve this is to use NFS over TCP. This would require the client to mount with the "tcp" option. Maybe with something like this:

192.168.1.130:/test /ijsbeer/test nfs rw,tcp,bg,soft,timeo=60 0 0


I am not fully versed on whether TCP NFS Server support is available in SuSE 9.0. You may be able to check by running this command on the server:

rpcinfo -p localhost

look for the network protocols associated with port 2049. Here's some sample output:


program vers proto port
...
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
...


If you can't do TCP NFS, you _MAY_ be able to mitigate this by specifying a small rsize and wsize in your client mount options. Something like maybe 1024 or evey 512.

I have just changed the fstab file
192.168.1.130:/test /ijsbeer/test nfs rw,tcp,bg,soft,timeo=60 0 0
It looks like the problem is solved.
Can you explain it to me ?
Manny thanks. This has stopt digging for a long time (months)

I can try to explain it.

UDP is essentially unreliable so there has to be a mechanism to timeout and recovery if a UDP fragment is lost in trasmisssion. Sadly, if you lose 1 IP fragment, NFS will re-read the entire block it was transmitting and send the whole thing over again.

In my case, our Load Balancer would fragment UDP packets. The vendor was unwilling to fix this problem. As a result, some large data transfers via UDP-NFS would severely slow all systems going through the load balancer and total throughput was low.

I can't say why you're UDP traffic was fragmented -- but a good rule of thumb is probably to use TCP for NFS -- especially for jobs requiring throughput.

manny thanks my frend