From: Neil Horman <nhorman@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Garrick Staples <garrick@usc.edu>, nfs@lists.sourceforge.net
Subject: Re: possible client stale filehandle bug?
Date: Wed, 26 Jan 2005 08:07:09 -0500 [thread overview]
Message-ID: <41F795FD.8010007@redhat.com> (raw)
In-Reply-To: <1106719587.10014.4.camel@lade.trondhjem.org>
Trond Myklebust wrote:
> ty den 25.01.2005 Klokka 09:39 (-0800) skreiv Garrick Staples:
>
>>Hi all,
>> I have lots of storage in a large Solaris samfs environment that is NFS
>>shared to a large number of Solaris and RHEL3 clients. Under some conditions,
>>linux apps have been getting stale filehandles during the normal course of
>>their activity. Various file handling syscalls like read() or open() might
>>error. Lots of renames and setattrs calls seem to trigger the problem.
>>'ci' and 'cvs commit' are particularly good at this.
>
>
> ESTALE is usually a sign that someone is deleting a file on the server
> that is in use by the client. It is a sign that you are doing something
> that violates the caching rules of NFS.
>
>
>>It seems that the Solaris clients never report any such errors, only the Linux
>>clients. However, watching 'snoop' on the Solaris NFS server, I see that it IS
>>returning stale file handles to both OSes, but Solaris clients seem to retry
>>the request several times; and the Linux clients immediately pass the error up
>>to the application.
>>
>>Is there some condition that the 2.4 kernel is handling incorrectly?
>
>
> I do not believe that Solaris redrives ESTALE on read, but they may do
> it on open(). Linux does not redrive either case. See the many
> discussions in the NFS list archives for why.
>
Solaris does in fact retry on operations on ESTALE errors, definately on
open, and I think on read/readdir/stat/etc. as well. We had some
discussion about tht here recently.
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2005-01-26 13:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-25 17:39 possible client stale filehandle bug? Garrick Staples
2005-01-26 6:06 ` Trond Myklebust
2005-01-26 6:35 ` Garrick Staples
2005-01-26 13:11 ` Neil Horman
2005-01-26 14:31 ` raven
2005-01-26 17:49 ` Garrick Staples
2005-01-28 0:49 ` Ian Kent
2005-01-26 13:07 ` Neil Horman [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-02-16 21:18 Lever, Charles
2005-02-16 21:23 ` Neil Horman
2005-02-24 19:33 ` Trond Myklebust
2005-02-24 20:43 ` nhorman
2005-02-16 21:42 Lever, Charles
2005-02-16 21:47 ` Neil Horman
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=41F795FD.8010007@redhat.com \
--to=nhorman@redhat.com \
--cc=garrick@usc.edu \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
/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