Thanks Trond!
I was referring to the 'standard' comment from the netapp PDF:
"Due to a bug in the mount command, the default retransmission timeout
value on Linux for NFS over TCP is quite small...To obtain standard
behavior, we strongly recommend using "timeo=600, retrans=2" explicitly
when mounting via TCP."
And was wondering what the 'standard' was. Chuck politely pointed me to
Solaris as the NFSv3 reference for 'standard'.
Thanks,
--Greg
Trond Myklebust wrote:
On Tue, 2006-07-11 at 14:00 -0500, Gregory Baker wrote:
We have thousands of linux clients hitting netapp file servers (many
3500 series, clustered) on a local gigabit LAN. From time to time,
applications return "file not found" when attempting to automount a
directory and access a file. An example of this is a long running
process, which reads in data, processes it for hours (in which time the
filesystem is unmounted) then tries to read more data from that mount
point (which causes a "file not found" error in the application). This
occurs about 1/100th of the time.
Researching at Netapp turns up this bit by Chuck Lever (Linux NFS
contributer)
"Using the Linux NFS Client with Network Appliance Filers"
http://www.netapp.com/libr ary/tr/3183.pdf (February 2006)
page 10 says...
"Due to a bug in the mount command, the default retransmission timeout
value on Linux for NFS over TCP is quite small...To obtain standard
behavior, we strongly recommend using "timeo=600, retrans=2" explicitly
when mounting via TCP."
Our defaults (assuming man pages are correct, RedHat Enterprise Linux 3)
would be timeo=7, retrans=3, which translates to 7+14+28+56 = 105 tenths
of a second (10 seconds). It appears netapp is suggesting waiting
600+600 = 1200 tenths (120 seconds) before giving up on the mount command...
No they are not. See below.
* What "bug" in the mount command do you believe NetApp is talking about?
It has nothing to do with the mount timeout: Chuck is talking about the
retransmission timeout for TCP connections 'timeo' which should indeed
be set to a high value since TCP guarantees message delivery (unlike UDP
which requires a small timeo value). Setting it too low means that you
end up spamming your server with a load of unnecessary retransmissions.
This was indeed the case for some older versions of 'mount' and also for
older versions of the am-utils/amd automounters.
* What do you think proper options for NFS auto/mounts would be for
extremely busy centralized NFS filers?
Something like
mount -t nfs -ohard,timeo=600,retrans=2,rsize=32768,wsize=32768,tcp foo:/ /bar
should be a fairly safe bet. You might want to add the 'intr' flag too,
depending on how you feel about the behaviour w.r.t. pressing ^C.
* What is the reference standard behavior?
To which reference are you referring?
Cheers,
Trond
--
----------------------------------------------------------------------
Greg Baker 512-602-3287 (work)
[EMAIL PROTECTED] 512-602-6970 (fax)
5900 E. Ben White Blvd MS 626 512-555-1212 (info)
Austin, TX 78741
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
