namecache work stage 4:
authorMatthew Dillon <dillon@dragonflybsd.org>
Thu, 8 Apr 2004 17:56:48 +0000 (17:56 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Thu, 8 Apr 2004 17:56:48 +0000 (17:56 +0000)
commitce6da7e429134352f8c0c4f57b639f7f54f2d32e
treeef5c09cf23fd836d0bb3ceae22a896333de1e441
parent0355acc1b51d46423d6b9c5e3f059cfa79b2224b
namecache work stage 4:

(1) Remove vnode->v_dd, vnode->v_ddid, namecache->nc_dvp_data, and
namecache->nc_dvp_id.  These identifiers were being used to detect stale
parent directory linkages in the namecache and were leftovers from the
original FreeBSD-4.x namecache topology.  The new namecache topology
actively discards such linkages and does not require them.

(2) Cleanup kern/vfs_cache.c, abstracting out allocation and parent
link/unlink operations into their own procedures.

(3) Formally allow a disjoint topology.  That is, allow the case where
nc_parent is NULL.  When constructing namecache entries (dvp,vp), require
that that dvp be associated with a namecache record so we can create the
proper parent->child linkage.  Since no naming information is known for
dbp, formally allow unnamed namecache records to be created in order to
create the association.

(4) Properly relink parent namecache entries when ".." is entered into
the cache.  This is what relinks a disjoint namecache topology after it
has been partially purged or when the namecache is instantiated in the
middle of the logical topology (and thus disjoint).

Note that the original plan was to not allow a disjoint topology, but after
much hair pulling I've come to the conclusion that it is impossible to do
this.  So the work now formally allows a disjoint topology but also, unlike
the original FreeBSD code, takes pains to try to keep the topology intact
by only recycling 'leaf' vnodes.  This is accomplished by vref()ing a vnode
when its namecache records have children.
sys/kern/vfs_cache.c
sys/kern/vfs_subr.c
sys/sys/namecache.h
sys/sys/vnode.h