cache_lookup() work this week.

Pawel Jakub Dawidek nick at garage.freebsd.pl
Wed Sep 3 05:20:22 PDT 2003


On Wed, Sep 03, 2003 at 12:20:42AM -0700, Matthew Dillon wrote:
+> :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.

You've wrote that "The one representing "d" will be a negative cache entry,
placemarking the operation.".
So maybe this negative entry could be treated as file in directory.
In other words 'lock d' will create some shade object in 'c' directory
(in namecache) and this will prevent removing 'c'. Or whatever...

-- 
Pawel Jakub Dawidek                       pawel at xxxxxxxxxxx
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 305 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20030903/eaa229d0/attachment-0016.obj>


More information about the Kernel mailing list