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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
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.