vnode leak in FFS code ... ?

[Matthew Dillon]

:...
:The part that hurts the most is that the longer the server is up and 
:running, the greater the chance of having a 12+hr fsck run due to all the 
:ZERO LENGTH DIRECTORYs :(
:
:Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
:Email: scrappy at hub.org           Yahoo!: yscrappy              ICQ: 7615664

    This may have been mentioned already but it occurs to me that the
    ZERO LENGTH DIRECTORIES are due to ffs not being able to immediately
    deactivate (INACTIVE) a vnode because a ref count is being held by
    unionfs.

    e.g. so if you rm -rf a directory under FFS, that directory inode 
    remains active (just like a remove()'d file remains active if one has
    an open file descriptor to it) until the last reference goes away,
    and unionfs is holding the last reference.

    One way to fix this would be to have some sort of vnode-based
    notification mechanism associated with the mount point (the mount
    structure), so unionfs could register itself in the underlying FS's
    mount structure to get a callback when the underlying FS wants to
    destroy a file or directory.  Then unionfs would be able to throw
    away the related uppervp or lowervp reference.

    An easy way to fix this, presuming that there are no bugs in unionfs
    keeping the underlying vnode from being dereferenced, is to have a
    system call which explicitly flushes all the vnodes with no references
    associated with a mount point.  You could then flush the unionfs mounts
    in order to synchronize the destruction of removed files & directories
    in underlying filesystems.  You could do this once an hour or so to
    greatly reduce the instances of 0-length directories.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>