Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
did you try "hard" in combination w/ "proto=tcp" ?
I just did, and nfs calls never terminate as well. But it doesn't surprise me, because man nfs says :
Code:
if the hard option is specified, NFS requests are retried indefinitely
What surprises me, is that man nfs explicitly says :
Code:
If the soft option is specified, then the NFS client fails an NFS request
after retrans retransmissions have been sent, causing the NFS client to return
an error to the calling application.
mount -t nfs qnap:/share/MD0_DATA/disk1 /whatever -o rsize=BLKSIZ,wsize=BLKSIZ,intr,soft,proto=tcp
then try again using with
Code:
dd if=/dev/zero of=/mnt/mynfs/test.dd bs=BLKSIZ
where BLKSIZ is whatever is defined in /usr/include/nfsd/const.h
if in doubt, set BLKSIZ=8192
thing is the TCP block size in Linux Kernels >= 2.4 is 32K, NFS version 2
has 8K defined and in NFS version 3 it is up to the server.
You may consider to drop the block size altogether (rzise,wsize &dd).
I've heard about some issues w/ Ubuntu mount.nfs but I am no Ubuntu expert. Sorry.
I tried to modify the options in /etc/exports, but when I disable/enable nfs my modifications are removed. And if I don't, I don't know if they are taken into account.
But I tried it anyway, with your blocksize suggestions, and it's still blocking.
I found that with sync writes (client side, ie dd -oflags=sync), nfs is not blocking indefinitely anymore.
But there is no mention of this anywhere in nfs documentations.
Also, the error is reported long after I unplug the cable (up to 15 minutes), but if I unplug the cable 10s, then plug it again, the error is reported just there.
And I would prefer to use async writes so I am still open to suggestions.
Last edited by contremaitre; 01-29-2010 at 02:00 AM.
We had the same problem here but after two days investigating it it seems we found an explanation for this. The default protocol for NFS clients is TCP which seems to set its own timeout value. If you use UDP as protocol NFS clients will consider the "timeo" parameter timeout value. After unplugging the network cable the client program will stop after exhausting the local buffer and the timeout time.
I am using UDP but nfs is still blocking.
It seems it depends if the local buffer is full or not.
If I open my files with the SYNC option, then the local buffer will never grow, and the timeout value will be respected.
Otherwise, it never times out.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.