ffs softdeps fix request

[Kirk McKusick]

> Date: Mon, 28 Feb 2005 19:00:21 -0500 (EST)
> From: Jeff Roberson <jroberson at chesapeake.net>
> To: Alfred Perlstein <alfred at freebsd.org>
> cc: fs at freebsd.org, Xin LI <delphij at freebsd.org>, phk at freebsd.org,
>         jeffr at freebsd.org, mckusick at mckusick.com
> Subject: Re: ffs softdeps fix request
> In-Reply-To: <20050228235123.GC81082 at elvis.mu.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-ASK-Info: Whitelist match [from jroberson at 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 at 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