On Fri, 19 Dec 2014 11:46:26 +0900 "J. R. Okajima" <hooanon05g@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
