From owner-freebsd-fs@FreeBSD.ORG Mon Feb 28 23:51:25 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8F2516A4D6; Mon, 28 Feb 2005 23:51:23 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE3AD43D46; Mon, 28 Feb 2005 23:51:23 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B95C15C98E; Mon, 28 Feb 2005 15:51:23 -0800 (PST) Date: Mon, 28 Feb 2005 15:51:23 -0800 From: Alfred Perlstein To: fs@freebsd.org Message-ID: <20050228235123.GC81082@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: jeffr@freebsd.org cc: Xin LI Subject: ffs softdeps fix request X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 23:51:26 -0000 There's an artifact of ffs softupdates that causes issues if a crash occurs while deleting or creating files. Basically, one can wind up with a directory that is empty, but the link count is artificially high. Then you can have a directory that is empty, but not removeable. It would be somewhat trivial to add some code to check the directory's contents when a VOP_RMDIR would have failed because of the link count check. But then my head went all explody when trying to figure out how that would impact the background fsck in progress. Any ideas? -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684