DragonFly kernel List (threaded) for 2003-09
Re: cache_lookup() work this week.
:On Tue, Sep 02, 2003 at 10:10:31PM -0700, Matthew Dillon wrote:
:+> [...] What this basically means is that vnodes cannot be
:+> recycled in the 'middle' of the topology, only at the leafs. This d=
:+> not present a big problem since files are always leafs. [...]
:And what with vn(4)? There we've a file that should be locked and it isn't
:quite a leaf... But maybe this problem doesn't exists here.
File locking is not effected by this work, nor is directory vnode locking
for the purposes of actually reading or writing the directory. What is
effected is how namespace lookups are locked.
:Sounds really, really cool.
:But I see one potential problem.
:In directory 'a' you've file 'b', and directory 'c' is empty.
: thread 1 thread 2
: lock b
: lock d
: remove c (is empty, so this can be done)
: rename b to d
Ah. I think this issue can be dealt with by observing that the
attempt to remove C will call cache_purge(C), which will then block
waiting on D's lock. i.e. it will not be able to purge C's namecache's
children until the rename operation is complete, and then it will notice
that the directory is not empty. I think the case only occurs when
one actually attempts to remove C.
I'll make sure the case is handled properly when I get to that point.
:It is really great that you've decide to clean up this area, I hope
:everything goes just fine. Good luck!
:Pawel Jakub Dawidek pawel@xxxxxxxxxxx
Yes, I think some truely horrendous amount of code is going to get
cleaned up with a new namecache implementation. Things like rename()
will become a whole lot less complex.