From owner-freebsd-fs@FreeBSD.ORG Sat Mar 12 18:59:38 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 779FE16A4CE; Sat, 12 Mar 2005 18:59:38 +0000 (GMT) Received: from beastie.mckusick.com (h000d932745f5.ne.client2.attbi.com [24.91.248.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4F9443D39; Sat, 12 Mar 2005 18:59:37 +0000 (GMT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.9) with ESMTP id j2C1HwqO070291; Fri, 11 Mar 2005 17:17:58 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200503120117.j2C1HwqO070291@beastie.mckusick.com> To: Alfred Perlstein In-Reply-To: Your message of "Mon, 28 Feb 2005 19:00:21 EST." Date: Fri, 11 Mar 2005 17:17:58 -0800 From: Kirk McKusick cc: Jeff Roberson cc: jeffr@freebsd.org cc: Xin LI cc: fs@freebsd.org Subject: Re: 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: Sat, 12 Mar 2005 18:59:38 -0000 > Date: Mon, 28 Feb 2005 19:00:21 -0500 (EST) > From: Jeff Roberson > To: Alfred Perlstein > cc: fs@freebsd.org, Xin LI , phk@freebsd.org, > jeffr@freebsd.org, mckusick@mckusick.com > Subject: Re: ffs softdeps fix request > In-Reply-To: <20050228235123.GC81082@elvis.mu.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII > X-ASK-Info: Whitelist match [from jroberson@chesapeake.net] (2005/02/28 17:18:16) > > On Mon, 28 Feb 2005, Alfred Perlstein wrote: > > > There's an artifact of ffs softupdates that causes issues if a crash > > occurs while deleting or creating files. > > > > You should really ask Kirk about this sort of thing. > > > 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 > > The background fsck assumes that the filesystem will act in expected ways. Notably, it will not "correct" improper reference counts. So, it would be OK to decide that it wanted to remove the directory, and to do so, provided that it consumed only two of the three reference counts on the directory inode. That is it could remove the name and contents of the directory, but it would have to leave the inode allocated (and unnamed) with a reference count of one. When the background fsck eventually came across it, it would decrement its reference count by one which would then cause it to be freed. Kirk McKusick