Re: [PATCH] dcache: return -ESTALE not -EBUSY on distributed fs race

[Jeff Layton <jeff.layton@primarydata.com>]

On Fri, 19 Dec 2014 11:46:26 +0900
"J. R. Okajima" <hooanon05g@gmail.com> wrote:

> 
> Dave Chinner:
> > We use file handles on local filesystems. They have exactly the same
> > semantics as NFS file handles and so local filesystems have the same
> > ESTALE exposure as "distributed" filesystems to this problem. i.e:
> 
> It is reasonable.
> But do you think ESTALE is good in case of __d_unalias()?
> 

I don't think you'll ever see __d_unalias called on a local fs, as the
__d_find_any_alias call should always return NULL on a local fs.

With a local fs, we always know that the dcache is correct (which is
why local fs' generally don't supply a d_revalidate method). The only
way to get to __d_unalias is for all of the following to be true:

- you're splicing a new dentry into the tree
- that new dentry is a directory
- the inode for it already has a dentry associated with it that's in a
  different place

...that can only happen in a remote filesystem. The only way for that
to occur on a local fs is for that fs to allow a directory to be
hardlinked, which should of course never happen.

As to whether ESTALE is as good as EBUSY there...I doubt it'll matter
much. Remote filesystems generally have to be able to cope with ESTALE
errors anyway, and I doubt a lot of userland code handles EBUSY
especially for this situation.

-- 
Jeff Layton <jlayton@primarydata.com>