Linux NFS development
 help / color / mirror / Atom feed
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

             reply	other threads:[~2006-07-11 19:02 UTC|newest]

Thread overview: 14+ 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox