Re: cache_lookup() work this week.

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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=
:oes
:+>     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!
:
:--=20
: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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>