Hi Al,
I think there might be a problem in the VFS with d_revalidate() not being
called enough on mountpoints. As far as I can tell from the printks in my AFS
stuff, it's only called on the mounted-on dentry, and not the vfsmount-root
dentry. However, with NFS at least (not so much AFS), can you trust that the
mount-root dentry still maps to the same inode and event if it does that that
inode is still up to date?
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.
In the kernel output, I see:
(1) Permission check on the root dir of /afs: volume ID 20000001, vnode ID 1:
[0ls ] ==> afs_permission({20000001:1},1,)
(2) Revalidation of the mountpoint dir in /afs (vnode ID 6):
[0ls ] ==> afs_d_revalidate({v={20000001:6} n=.cambridge.redhat.com fl=20},)
[0ls ] not promised
(3) At this point, the stats of the mounted-on dir are rechecked.
[0ls ] new promise [fl=20]
(4) Permission check on the root dir of /afs/.cambridge.redhat.com (volume ID
20000003, vnode ID 1):
[0ls ] ==> afs_permission({20000003:1},1,)
(5) Revalidation of the mountpoint dir in /afs/.cambridge.redhat.com (vnode ID
2):
[0ls ] ==> afs_d_revalidate({v={20000003:2} n=afsdoc fl=20},)
[0ls ] not promised
(6) Again, the stats of the mounted-on dir are rechecked.
[0ls ] new promise [fl=20]
I was expecting to see the root dentry of each vfsmount be revalidated, but
that doesn't occur.
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
