HELP: NFS mount hangs when attempting to copy file

I'm having a bit of a problem doing simple copies over an NFS mount.
The client is running Linux (2.6.11), and the server is running Solaris
(5.8).

When I first boot the client, getting NFS directory listings works just
fine. But the instant I try to copy a file (to or from), the NFS mount
hangs. While I can still do other network activity (even rlogin to the
server), any NFS access I try to do after that point hangs, including
directory listings.

I have had this same client and server working flawlessly for years.
The only change is that the client is now on a VPN. However, I have a
Sun machine on the same VPN network segment, and it can copy files with
no problem, so it's not the router that's blocking anything.

Also, after it hangs like that, I cannot reboot the machine normally.
When attempting to unmount the network filesystems, the shutdown hangs,
and I have to hard-reset the machine.

Is there anyone who could please help me to debug this problem? I
don't even know how to watch to see if there's any network traffic. As
far as I know, I have NFS setup properly, but I don't know enough about
it to know what options I might try. I don't even care if the fix
degrades performance; I just want it to not hang.

Does anyone have any ideas?

Thanks very much in advance!

Timothy Miller <(E-Mail Removed)> wrote:

> I'm having a bit of a problem doing simple copies over an NFS mount.
> The client is running Linux (2.6.11), and the server is running Solaris
> (5.8).
>
> When I first boot the client, getting NFS directory listings works just
> fine. But the instant I try to copy a file (to or from), the NFS mount
> hangs. While I can still do other network activity (even rlogin to the
> server), any NFS access I try to do after that point hangs, including
> directory listings.
>
> I have had this same client and server working flawlessly for years.
> The only change is that the client is now on a VPN. However, I have a
> Sun machine on the same VPN network segment, and it can copy files with
> no problem, so it's not the router that's blocking anything.

I had a similar problem when my 100Mbps switch blew up and I temporarily
replaced it with a 10Mbps hub. I got around it by experimenting with the
soft, rsize, wsize and timeo mount options. "man mount" will tell you
more.

--
Andy.

Thank you for responding. One thing I'm having trouble finding out is
what the default rsize and wsize numbers are. And should I try larger
or smaller?

Thanks.

Timothy Miller <(E-Mail Removed)> wrote:

> Thank you for responding. One thing I'm having trouble finding out is
> what the default rsize and wsize numbers are. And should I try larger
> or smaller?

I think I read somewhere that it's 4096 bytes for Linux. 1024 worked
well for me so maybe start there.

--
Andy.

In comp.os.linux.networking Timothy Miller <(E-Mail Removed)>:

[ NFS problems through VPN - solaris server <-> linux client ]

> Also, after it hangs like that, I cannot reboot the machine normally.
> When attempting to unmount the network filesystems, the shutdown hangs,
> and I have to hard-reset the machine.

Try mounting with "soft" as option.

> Is there anyone who could please help me to debug this problem? I
> don't even know how to watch to see if there's any network traffic. As
> far as I know, I have NFS setup properly, but I don't know enough about

Since you don't post your mount options we don't know the
settings.

I'd try mounting with "tcp", IIRC solaris defaults to udp, but
this is changing sometimes and from OS to OS so one can't really
tell for sure.

Lowering r/wsize as someone else already pointed out is another
thing to try out. Try going for the highest nfs version possible.

[..]

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 73: Daemons did it

Ok, here's an example of one of the mounts from /proc/mounts (just
found out about that):

fish:/export/home/tim /home/tim nfs
rw,v3,rsize=32768,wsize=32768,hard,udp,lock,addr=s un 0 0

Ok, so clearly, the default transfer size is WAY larger than any of us
expected. I wonder how that default got in there.

I've read that soft-mounting often causes havoc. If it actually DOES
timeout, bad stuff happens. What is your experience and reasoning
here?

I'll fiddle with all of the other settings. Thanks.

In comp.os.linux.networking Timothy Miller <(E-Mail Removed)>:
> Ok, here's an example of one of the mounts from /proc/mounts (just
> found out about that):

> fish:/export/home/tim /home/tim nfs
> rw,v3,rsize=32768,wsize=32768,hard,udp,lock,addr=s un 0 0

> Ok, so clearly, the default transfer size is WAY larger than any of us
> expected. I wonder how that default got in there.

Haven't seen this as default r/wsize on any distro whatever you
run? But a good value on a LAN, the default is about 8192 on many
systems. But those seem to change from time to time.

But might be one of the problems on your VPN, I'd lower this and
switch to "tcp" instead of "udp" at first.

> I've read that soft-mounting often causes havoc. If it actually DOES
> timeout, bad stuff happens. What is your experience and reasoning
> here?

My experience is exactly different, many problems with hard
mounting and zero with soft mounting.

> I'll fiddle with all of the other settings. Thanks.

Yep, the difference with tcp instead of udp would be most
interesting, if the server supports that.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 325: Your processor does not develop enough heat.