DragonFly BSD
DragonFly kernel List (threaded) for 2003-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cache_lookup() work this week.

From: Pawel Jakub Dawidek <nick@xxxxxxxxxxxxxxxxx>
Date: Wed, 3 Sep 2003 08:50:29 +0200

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@xxxxxxxxxxx
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net

Attachment: pgp00001.pgp
Description: PGP signature

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]