Hi Al,
What d_xxx() functions should I call at the end of a filesystem mkdir() op?
It would seem that I've got two choices:
(1) just d_instantiate() (as ext2), or
(2) d_instantiate() and d_rehash() both (as NFS).
If I pick (1), then if I do:
mkdir /afs/.cambridge.redhat.com/afsdoc/jump/q
I see:
==> afs_permission({{20000001:1},0},1,)
==> afs_d_revalidate({v={20000001:6} n=.cambridge.redhat.com fl=20},)
==> afs_permission({{20000003:1},0},1,)
==> afs_d_revalidate({v={20000003:2} n=afsdoc fl=20},)
==> afs_permission({{20000006:1},0},1,)
==> afs_d_revalidate({v={20000006:5} n=jump fl=0},)
==> afs_permission({{20000006:5},0},1,)
==> afs_permission({{20000006:5},0},1,)
==> afs_lookup({20000006:5},ffff81003344cac8{q},)
==> afs_permission({{20000006:5},0},3,)
==> afs_mkdir({20000006:5},{q},755)
vnode modified 13 on {20000006:5}
not hashed
==> afs_d_delete(jump)
The "not hashed" indicates that d_unhashed() was true when called after the
d_instantiate().
And then if I do:
ls /afs/.cambridge.redhat.com/afsdoc/jump/q
I see:
==> afs_permission({{20000001:1},0},1,)
==> afs_d_revalidate({v={20000001:6} n=.cambridge.redhat.com fl=20},)
==> afs_permission({{20000003:1},0},1,)
==> afs_d_revalidate({v={20000003:2} n=afsdoc fl=20},)
==> afs_permission({{20000006:1},0},1,)
==> afs_d_revalidate({v={20000006:5} n=jump fl=c},)
==> afs_permission({{20000006:5},c},1,)
==> afs_lookup({20000006:5},ffff81003344c9c0{q},)
zap data {20000006:5}
==> afs_d_delete(q)
In this case, afs_lookup() is called extraneously... But it does seem to
work.
However, if I pick (2), an do the mkdir, I see:
==> afs_permission({{20000001:1},0},1,)
...
==> afs_lookup({20000006:5},ffff81003344c180{q},)
==> afs_permission({{20000006:5},0},3,)
==> afs_mkdir({20000006:5},{q},755)
vnode modified 1b on {20000006:5}
not hashed
Which is as before, except that afs_d_delete() is *not* called. Then if do
the "ls" again, I see:
==> afs_permission({{20000001:1},0},1,)
==> afs_d_revalidate({v={20000001:6} n=.cambridge.redhat.com fl=20},)
==> afs_permission({{20000003:1},0},1,)
==> afs_d_revalidate({v={20000003:2} n=afsdoc fl=20},)
==> afs_permission({{20000006:1},0},1,)
==> afs_d_revalidate({v={20000006:5} n=jump fl=c},)
==> afs_permission({{20000006:5},c},1,)
==> afs_permission({{20000001:1},0},1,)
==> afs_d_revalidate({v={20000001:6} n=.cambridge.redhat.com fl=20},)
==> afs_permission({{20000003:1},0},1,)
==> afs_d_revalidate({v={20000003:2} n=afsdoc fl=20},)
==> afs_permission({{20000006:1},0},1,)
==> afs_d_revalidate({v={20000006:5} n=jump fl=c},)
==> afs_permission({{20000006:5},c},1,)
==> afs_permission({{20000006:7},0},4,)
There's no call to afs_d_revalidate() for 'q' which is decidedly fishy...
Furthermore:
(1) d_release() isn't called for 'q' when I unmount the filesystem.
(2) if I delete 'q' on the server and do the ls again, then although listing
jump no longer shows 'q' to be there, the dentry is clearly still there
as I can list it directly:
[root@andromeda ~]# mkdir /afs/.cambridge.redhat.com/afsdoc/jump/q
[root@andromeda ~]# ls /afs/.cambridge.redhat.com/afsdoc/jump/q
[root@andromeda ~]# ls /afs/.cambridge.redhat.com/afsdoc/jump
q/
<delete 'q' on server>
[root@andromeda ~]# ls /afs/.cambridge.redhat.com/afsdoc/jump
[root@andromeda ~]# ls /afs/.cambridge.redhat.com/afsdoc/jump/q
[root@andromeda ~]#
Any suggestions as what I need to do? I've tried working it out from NFS, but
I must have missed something.
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
