From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 18:57:42 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF6FA16A4CE; Sat, 4 Sep 2004 18:57:42 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94BFD43D1F; Sat, 4 Sep 2004 18:57:42 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i84Ivela046690; Sat, 4 Sep 2004 11:57:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i84Ive1n046689; Sat, 4 Sep 2004 11:57:40 -0700 (PDT) (envelope-from dillon) Date: Sat, 4 Sep 2004 11:57:40 -0700 (PDT) From: Matthew Dillon Message-Id: <200409041857.i84Ive1n046689@apollo.backplane.com> To: "Marc G. Fournier" References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca><41365746.2030605@samsco.org> <20040901224632.O72978@ganymede.hub.org> <41394D0B.1050004@elischer.org> <20040904131131.A812@ganymede.hub.org> cc: Allan Fields cc: freebsd-stable@freebsd.org cc: Julian Elischer cc: freebsd-current@freebsd.org Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 18:57:43 -0000 :... :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@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