From: "Gregory Baker" <gregory.baker@amd.com>
To: nfs@lists.sourceforge.net
Cc: autofs@linux.kernel.org
Subject: bug in linux mount? (says NetApp)
Date: Tue, 11 Jul 2006 14:00:23 -0500 [thread overview]
Message-ID: <44B3F547.9010507@amd.com> (raw)
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...
* What "bug" in the mount command do you believe NetApp is talking about?
* What do you think proper options for NFS auto/mounts would be for
extremely busy centralized NFS filers?
* What is the reference standard behavior?
Thanks,
--Greg
--
----------------------------------------------------------------------
Greg Baker 512-602-3287 (work)
gregory.baker@amd.com 512-602-6970 (fax)
5900 E. Ben White Blvd MS 626 512-555-1212 (info)
Austin, TX 78741
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next reply other threads:[~2006-07-11 19:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 19:00 Gregory Baker [this message]
2006-07-11 20:21 ` bug in linux mount? (says NetApp) Chuck Lever
2006-07-14 20:36 ` Gregory Baker
2006-07-11 23:27 ` [NFS] " Trond Myklebust
2006-07-11 23:34 ` Gregory Baker
2006-07-12 3:03 ` [autofs] " Ian Kent
2006-07-12 12:19 ` Trond Myklebust
2006-07-12 9:32 ` James Pearson
2006-07-12 0:40 ` Blake Golliher
2006-07-12 1:07 ` Gregory Baker
-- strict thread matches above, loose matches on Subject: below --
2006-07-12 2:13 Gomez, Daniel
2006-07-12 2:13 ` Gomez, Daniel
2006-07-12 20:23 Murata, Dennis W (SAIC)
2006-07-12 20:23 ` Murata, Dennis W (SAIC)
2006-07-13 12:55 ` Ian Kent
2006-07-13 13:37 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44B3F547.9010507@amd.com \
--to=gregory.baker@amd.com \
--cc=autofs@linux.kernel.org \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.