vnode leak in FFS code ... ?
dillon at apollo.backplane.com
Sat Sep 4 11:57:42 PDT 2004
: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
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.
<dillon at backplane.com>
More information about the freebsd-current