cache_lookup() work this week.

[Pawel Jakub Dawidek]

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 does
+>     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.

+>     The third step will be to use the namecache for all name-based locking
+>     operations instead of the underlying vnodes.  For example, if you
+>     are renaming a/b to c/d you only need to hold locks on the namecache
+>     entry representing "b" and the one representing "d" prior to executing
+>     the rename operation. [...]

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

+>     The fourth step will be a *BIG* Carrot... the namecache topology does
+>     not have a problem with vnodes appearing in multiple places in the
+>     filesystem.  This means that (A) it will be possible to hardlink
+>     directories and (B) it will be possible to implement semi-hard links,
+>     basically softlinks that *look* like hardlinks and (C) to be able to 
+>     CD forwards and backwards without the system getting confused about
+>     paths.  In other words, some way cool shit.

That's for sure!:)

+>     Additional optimizations are possible for the future.  For example,
+>     it will be possible to cache ucred pointers in the namecache structure
+>     and thus allow namei() to *COMPLETELY* resolve a path without making
+>     any VOP calls at all, which will at least double and probably quadruple
+>     best case path lookup performance.
+> 
+>     I'll post an update after step 3, probably near the end of the week or
+>     on the weekend.  I expect people will start screaming for Step 4 now
+>     that they know it is possible :-)

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 at xxxxxxxxxxx
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net
Attachment:
pgp00001.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 305 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20030902/8ad3b058/attachment-0020.obj>