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:

        [EMAIL PROTECTED] ~]# mkdir /afs/.cambridge.redhat.com/afsdoc/jump/q
        [EMAIL PROTECTED] ~]# ls /afs/.cambridge.redhat.com/afsdoc/jump/q
        [EMAIL PROTECTED] ~]# ls /afs/.cambridge.redhat.com/afsdoc/jump
        q/
     <delete 'q' on server>
        [EMAIL PROTECTED] ~]# ls /afs/.cambridge.redhat.com/afsdoc/jump
        [EMAIL PROTECTED] ~]# ls /afs/.cambridge.redhat.com/afsdoc/jump/q
        [EMAIL PROTECTED] ~]#

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to