From: Neil Brown <neilb@cse.unsw.edu.au>
Subject: Re: NFS server reports stale handles intermittently
Date: Mon, 8 Apr 2002 13:12:03 +1000 (EST)
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <15537.2691.713117.44648@notabene.cse.unsw.edu.au>
References: <009101c1dc62$2510ac80$47426682@csee.uq.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: <nfs@Lists.sourceforge.net>
To: "Chris Pascoe" <c.pascoe@itee.uq.edu.au>
In-Reply-To: message from Chris Pascoe on Friday April 5
Errors-To: nfs-admin@lists.sourceforge.net

On Friday April 5, c.pascoe@itee.uq.edu.au wrote:
> Hi,
> 
> I'm trying to track down problems with NFS exports of a large XFS
> partition that's only become apparent when the server went into production
> (of course it didn't show up in 6 months of stability testing!).

Isn't that always the way...

> 
> In my find test, all the stale handles are returned for directories that I
> have no access to the contents of;

This seems to suggest that the problem happens when nfsd has to do a
lookup of ".." in a directory as it has to do when you access a
directory that has fallen out of cache (it has to put it backin cache
by finding a full path name).
However the lookup("..") happens below the normal permission checking
so this shouldn't be a problem.... I had a look at a couple of XFS
patches and they don't seem to do any extra permission checking so it
doesn't seem to be that...


>                                    however we have seen stale handles
> returned for binaries that are most definitely accessible to users (like
> window managers, etc), and mail folders, etc.

If the problem is related to building a patch back to the root, then
you can remove the problem for non-directories by exporting with
"no_subtree_check". 

NeilBrown

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs