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

  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