Date: Fri, 11 Mar 2005 17:17:58 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: Alfred Perlstein <alfred@freebsd.org> Cc: fs@freebsd.org Subject: Re: ffs softdeps fix request Message-ID: <200503120117.j2C1HwqO070291@beastie.mckusick.com> In-Reply-To: Your message of "Mon, 28 Feb 2005 19:00:21 EST."
next in thread | raw e-mail | index | archive | help
> Date: Mon, 28 Feb 2005 19:00:21 -0500 (EST) > From: Jeff Roberson <jroberson@chesapeake.net> > To: Alfred Perlstein <alfred@freebsd.org> > cc: fs@freebsd.org, Xin LI <delphij@freebsd.org>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503120117.j2C1HwqO070291>