File trees: the deeper, the weirder

[Matthew Dillon]

    It's possible to allow intermediate directory vnodes to be reclaimed by
    adjusting cache_leaf_check(), etc, but doing so will cause the kernel
    getcwd to fail a lot more often.  This is, in fact, how reclamation worked
    before I added cache_leaf_check().  That work was never completed in
    FreeBSD (I finished it in DragonFly).  It probably wouldn't hurt a
    whole lot to nerf it, since I don't think there is anyone in FreeBSDland
    really interested in converting the namecache from a vnode-centric
    topology to an independant namecache-centric topology like we have
    in DragonFly.

    Still, I wouldn't remove it entirely.  Directory vnodes have a tendency
    to go by the wayside during scans (tar, find, etc) and get recycled far
    earlier then they otherwise should.

    The bigger issue with regards to vnode recycling is the VM page cache.
    Vnodes with cached VM pages do not usually get recycled and the vnode
    system relies on the VM system's page recycling to eventually free up
    all the VM pages associated with a vnode and make it recyclable.  But
    on modern systems with tons of physical memory accessing lots of tiny
    files it is possible to have plenty of free memory but still have too
    many unrecyclable vnodes due to the presence of cached VM pages for
    those vnodes.

    There is code in vlrureclaim() that tries to solve this problem by
    calculating a 'trigger' point -- all VM objects with less then the
    trigger point number of cached VM pages are considered recyclable.
    See line 566 in vfs_subr.c in FreeBSD HEAD.  This calculation is
    fairly primitive in FreeBSD.  There is a more sophisticated version
    in DragonFly which scales the trigger point up when the vnode recycler
    detects that it is having problems.  You should look at it.  Line 501
    in kern/vfs_mount.c in DragonFly HEAD is a good starting point.

						-Matt