Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote:
> > I discovered it because I was relying on d_revalidate() to spot that the
> > server had broken the callback on a directory that had been changed.
> > However, the root directory of each volume isn't being d_revalidated.
>
> That sounds like an abuse. You are not revalidating the path itself
> (which is the purpose of d_revalidate). Instead you are revalidating the
> directory metadata, which is a very different thing.
More to the point I'm attempting to revalidate the contents of the directory,
so that I can honour the next d_revalidate() call down the line. There is no
lookup op in AFS as there is in NFS: the way things are done is that the
client's lookup parses the directory blob to map a name to a FID.
Maybe then what I need to do is revalidate the parent directory's contents in
each d_revalidate(). That has fun with rename, but if I do it under get ref
and lock, it should be okay. I'll just have to be careful to avoid deadlock.
Alternatively, is the permission() call made prior to each d_revalidate()? If
so, maybe I can use that:
[0ls ] ==> afs_permission({{20000001:1},0},1,)
[0ls ] ==> afs_d_revalidate({v={20000001:6} n=.cambridge.redhat.com fl=20},)
[0ls ] ==> afs_permission({{20000003:1},0},1,)
[0ls ] ==> afs_d_revalidate({v={20000003:2} n=afsdoc fl=20},)
[0ls ] ==> afs_permission({{20000006:1},0},1,)
[0ls ] ==> afs_d_revalidate({v={20000006:4} n=NEWS fl=0},)
Except that that doesn't get called on the last item in the chain (if I do,
say, just an ls of it). That probably means I need to make the getattr() op
do content revalidation too.
David
-
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
