Re: ESTALE errors: What can be done to handle this problem.

["J. Bruce Fields" <bfields@redhat.com>]

On Tue, Apr 10, 2012 at 04:57:42PM +0000, Myklebust, Trond wrote:
> Handling ESTALE still doesn't guarantee that you can make progress.
> Remove the 'sleep 3' above, and you can theoretically find yourself
> replaying lookups until the cows come home while that 'stat()' call
> continues to return ESTALE.
> The bottom line is that NFS is not safe in situations such as the above,

By the way, what precisely are the "situations such as the above"?  Or
put in another way, what are the rules users need to know?

("Operations on paths affected by a directory-modifying operation should
not be attempted until after sufficient time has passed for the lookup
cache to time out"?  No, it should be a weaker rule than that.)

> since we don't have the kind of locking required to guarantee that
> LOOKUP + GETATTR can be done atomically.

Though all we actually need is a way to hold a temporary reference on
the looked up filehandle.  In theory that wouldn't be hard to add?:

	- Clarify that current and saved filehandles shouldn't go stale
	  during the lifetime of a compound.
	- If we also need to hold filehandle references across
	  compounds, introduce new operations for that (and make the
	  references part of the client's leased state)

--b.

> 
> > Is this approach feasible? If not, what else can be done to avoid this
> > problem.
> 
> If you have workloads such as the above, then I suggest "mount
> -olookupcache=none". It still won't prevent ESTALE, but at least you
> ensure that the dentry revalidation always does a full lookup.
> 
> Otherwise, you can do as Jeff suggested: handle the ESTALE at the VFS
> level, but ensure that you break out of the loop after a limited number
> of attempts has been made.
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
>