NFS server not responding over WAN with large file

[jerry1]

Has anyone seen this NFS problem.

I have made two test files.
One which is 14628 bytes, as listed with ll.
And the other 14629 bytes.

I can cp the 14628 byte file over NFS mount but
anything over this size generates the message:

NFS server not responding.

The last time I had a problem like this was
with an ISP that had a router configured with
an mtu of 1486 instead of the ethernet mtu
standard of 1500. Had to change our mtu to
match theirs so things would work.

Also. I can cp large files fine from the NFS mount. Just can't write to them.

This problem is only with systems not on the
lan. ftp, smtp works fine for large files.

[Geoff Wild]

Havn't seen it - but I would read the following - in particular th section on mount options:

http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,952,00.html

Rgds...Geoff

[A. Clay Stephenson]

NFS over the WAN is something to be avoided if possible but nonetheless I've always been able to make it work. A good place to start would be a series of nfsstats and see if anything jumps out at you either on the client or server end.

[Todd McDaniel_1]

Jerry,

Regarding not being able to cp to the NFS mount... check the options on the NFS filesystem on the server, and be sure it is NOT read only. That could be the problem.

On the filesize limitation problem, I think if you can try to rcp or ftp a file from/to the NFS server. That may give you a clue. Also, look at the syslog.log to see if that can give you any clues.

Also, which way are you cp'ing the 14628 byte file? I am assuming FROM the NFS server to the client.

[G. Vrijhoeven]

Hi,

I found a patch you might want to check:

http://www4.itrc.hp.com/service/cki/patchDocDisplay.do?patchId=PHNE_28138

It states:
Intergraph's DiskShare NFS server returns zero bytes for the
preferred and/or maximum transfer size of READ/WRITE, which
makes the HP-UX NFS client panic. The correct behavior
should be to 1) return an I/O error message when the
preferred and/or maximum size has a value of zero, and 2)
allow normal operation when the maximum transfer size has a
non-zero value.

Resolution:
When an NFS server returns zero or MAX_LARGE_FILES for a
READ/WRITE operation's transfer size, the HP-UX client now
responds correctly instead of panicking.


HTH,

Gideon

[Jim Butler]

I have seen issues with different versions of nfs.
You can see the stats with the nfsstat commands (man page available )

I would recommend trying nfs2 to start (automount) and disabling autofs.

Sounds like you have one of the old forward compatible to system A but not backward compatible to system B type issues. Force the OLD version only, and work from there.

[Jim Butler]

I have seen issues with different versions of nfs.
You can see the stats with the nfsstat commands (man page available )

I would recommend trying nfs2 to start (automount) and disabling autofs.

Sounds like you have one of the old forward compatible to system A but not backward compatible to system B type issues. Force the OLD version only, and work from there.

Oh - forgot - /etc/rc.config.d/nfsconf
is the file you want to look at for the version.

[jerry1]

The NFS tech doc is interesting. Thanks Geoff.

nfsstat is good but I can't really make heads or tails from the output. Thanks anyway Clay. I'll read up on it. I agree also. NFS is not something you want implemented over a WAN.

I had recommended to the other site that they
use rcp or ftp. It seemed to work okay.
The problem of course is not permissions since I do not get an error message regarding
permissions. I trying to copy from the client to the NFS mount from the NFS server Todd. Thanks Todd for the input on rcp an ftp though.

There is no problem with system panics or
hangs and the patch does not describe the
current problem we are now experiencing that
we were not having before. Thanks G. for the
effort.

Unfortunately I cannot just change the other
sites nfs functionality. And since it was
working before and nothing has changed on the
systems. It leads me to believe that there
was a network change. Thanks anyway Jim.
I wish I did have more control on other systems to trouble shoot problems better.

Turns out that they added a switch under the
desk that was causing the problem. If they
take the switch out of the loop then cp works. No telling how the switch is configured or if there is something broke on it. The tech doc nfs performance talks about problems like this with bad hardware.

[jerry1]

Found from nfsstat -m that HP's default protocol for NFS is udp. On Sun it is TCP.
I set the flag in /etc/rc.config.d/nfsconf to
NFS_TCP=1 and this fixed the problem for NFS
over the WAN.

[Jeff Schussele]

HI Jerry,

Thanks for posting your solution. Far too few users do.

As to the solution, that would definitely explain it. You'll find NFS via TCP will be more robust & less prone to trouble, but somewhat slower do to the CRC routines required by TCP but not UDP.

But I always refer to NFS as
Not F'n Stable anyway ;~))
And I always cringe when I have to implement it in Production.

Rgds,
Jeff