From: David Howells <dhowells@redhat.com>
To: viro@zeniv.linux.org.uk
Cc: trond.myklebust@fys.uio.no, linux-fsdevel@vger.kernel.org,
dhowells@redhat.com
Subject: What should dcache routines should be called at the end of mkdir?
Date: Wed, 18 Apr 2007 17:36:09 +0100 [thread overview]
Message-ID: <4432.1176914169@redhat.com> (raw)
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
next reply other threads:[~2007-04-18 16:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-18 16:36 David Howells [this message]
2007-04-18 21:00 ` What should dcache routines should be called at the end of mkdir? David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4432.1176914169@redhat.com \
--to=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.