Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
NFS, client to server, time too large
distribution: SuSE 9.0 on both machines
Shared dir: /test
On client mounting at startup
192.168.1.130:/test /ijsbeer/test nfs defaults 0 0
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.
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:
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)
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:
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)
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.