[OpenAFS-devel] Re: afs_linux_dentry_revalidate and d_drop

Andrew Deason adeason@sinenomine.net
Fri, 14 Mar 2014 14:50:01 -0500


On Fri, 14 Mar 2014 07:07:37 -0400
chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> wrote:

> I think (it has been a while) that the pioctl() happens, a callback
> from the fileserver occurs, and the version number for the afs inode and
> dentry no longer match for the containing directory forcing a
> revalidate of the directory's contents.
> 
> It does feel like there could be a race in there as well.

I don't think so. We don't get a callback break for modification events
we generate; we just modify our local cache if it's up to date. That is,
the AFS cache, not the Linux VFS cache.

The rest of that, though (DV mismatch, so we try to revalidate), yes,
that sounds about right.

> > One possible way of improving this is to maybe d_drop in
> > afs_linux_dentry_revalidate if we know that the entry does in fact no
> > longer exist (ENOENT), and d_invalidate for all other errors. But I'm
> > not sure if that's necessary or at all correct.
> 
> This might be a candidate for sillyrename.  Something is in use but
> hasn't lost all references just yet.

I don't think we'd need sillyrename; we don't need to keep the actual
file contents alive on the fileserver. But I'm not thinking about it too
deeply right now.

-- 
Andrew Deason
adeason@sinenomine.net