From owner-freebsd-arch  Thu Mar 29 21:58:19 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184])
	by hub.freebsd.org (Postfix) with ESMTP id 926A437B718
	for <arch@freebsd.org>; Thu, 29 Mar 2001 21:58:13 -0800 (PST)
	(envelope-from mckusick@mckusick.com)
Received: from beastie.mckusick.com (localhost [127.0.0.1])
	by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id VAA09201;
	Thu, 29 Mar 2001 21:58:11 -0800 (PST)
	(envelope-from mckusick@beastie.mckusick.com)
Message-Id: <200103300558.VAA09201@beastie.mckusick.com>
To: Bakul Shah <bakul@bitblocks.com>
Subject: Re: Background Fsck 
Cc: arch@freebsd.org
In-Reply-To: Your message of "Thu, 29 Mar 2001 16:53:55 PST."
             <200103300053.TAA27553@thunderer.cnchost.com> 
Date: Thu, 29 Mar 2001 21:58:11 -0800
From: Kirk McKusick <mckusick@mckusick.com>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	To: Kirk McKusick <mckusick@mckusick.com>
	cc: arch@freebsd.org
	Subject: Re: Background Fsck 
	In-Reply-To: Your message of "Wed, 28 Mar 2001 21:22:10 PST."
		     <200103290522.VAA06966@beastie.mckusick.com> 
	Date: Thu, 29 Mar 2001 16:53:55 -0800
	From: Bakul Shah <bakul@bitblocks.com>

	Dumb question time.  Why would I want to run a background
	fsck on an active filesystem? One wouldn't mount an unsafe
	filesystem in the first place.

Background fsck can only be run on filesystems that are using
soft updates. It is safe to mount a soft updates filesystem 
after a crash because the only inconsistencies will be lost
block and inodes. So, in a sense you are mouting a dirty
filesystem, albeit one on which it is safe to operate.

	Perhaps you are talking about background garbage collection
	on an active fs -- blocks and inodes not reachable from
	the root set of objects (root inode + freelist + superblock?)
	recovered lazily.  If this is really what you have, wouldn't
	it make sense to call it something else (e.g. fsgc)?

I agree that background fsck is doing garbage collection, but then
one can argue that traditional fsck is doing garbage collection
too. It might have been reasonable to call the original program
fsgc, but it was called fsck. The background fsck is doing exactly
the same set of fixes that the traditional fsck does. The only
difference is that it has to do system calls to update the bitmaps
rather than writing them directly. So, changing the name seems
unnecessarily confusing to me.

	On a somewhat related note, I have always wondered if the
	current fsck algorithm can be significantly improved or if it
	is about as efficient as it can be (barring any peephole code
	improvements).

Many improvements have been made to fsck over the years. Through
there are undoubtedly more that could be made, there are no big
easy improvements left.

	Kirk

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message