All of lore.kernel.org
 help / color / mirror / Atom feed
From: Garrick Staples <garrick@usc.edu>
To: nfs@lists.sourceforge.net
Subject: Re: possible client stale filehandle bug?
Date: Tue, 25 Jan 2005 22:35:47 -0800	[thread overview]
Message-ID: <20050126063547.GS12269@polop.usc.edu> (raw)
In-Reply-To: <1106719587.10014.4.camel@lade.trondhjem.org>

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

On Tue, Jan 25, 2005 at 10:06:27PM -0800, Trond Myklebust alleged:
> 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.

Nothing of the kind is happening here.  I've tested this a thousand times over
the last few days trying to find a solution.  In this case, Sun's samfs
filesystem is definitely at fault and doing the wrong thing.  Backline
engineers at Sun confirm this and are working on a fix.  

The reason for _this_ email isn't because of the ESTALEs, it's regarding the
handling of the ESTALEs.  Right now I need the Solaris client behaviour to
deal with this particular buggy server.

Incidentally, 2.6.10 never has a problem.  It's behaviour never creates ESTALEs in
the first place.

 
> > 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.

Did you look at the 'snoop' bits in the previous email?  During that time, the
process on the Solaris client is hanging in a write() call.

I'd be very happy to see any patches lieing around that might do this
behaviour.  It would get me through the short term until Sun fixes this bug in
samfs.

-- 
Garrick Staples, Linux/HPCC Administrator
University of Southern California

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-01-26  6:35 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 [this message]
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
  -- 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=20050126063547.GS12269@polop.usc.edu \
    --to=garrick@usc.edu \
    --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.