| 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