From owner-freebsd-questions@FreeBSD.ORG Thu Aug 23 17:57:32 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8808016A41B for ; Thu, 23 Aug 2007 17:57:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 3E21313C46A for ; Thu, 23 Aug 2007 17:57:30 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id DAA23909; Fri, 24 Aug 2007 03:57:17 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 24 Aug 2007 03:57:16 +1000 (EST) From: Ian Smith To: CyberLeo Kitsana In-Reply-To: <46CDADF4.5070801@cyberleo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Chris , freebsd-questions@freebsd.org, Bill Moran Subject: Re: fsck strangeness X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2007 17:57:32 -0000 On Thu, 23 Aug 2007, CyberLeo Kitsana wrote: > Ian Smith wrote: > > My knowledge of this is thin, despite reading McKusick's paper through > > several times, but we're told that background fsck runs on a snapshot of > > the fs concerned. How any bg fsck corrections are woven back into the > > live fs later is still a mystery to me, but that's because I still have > > an only barely superficial understanding of how snapshots work .. > > Background FSCK only repairs a small subset of filesystem > incosistencies. Specifically, those inconsistencies that softupdates > allows to occur, such as data blocks allocated out of the bitmap, but > not actually assigned to any inode. Background FSCK only needs to find > these (by looking at a fully consistent and unchanging snapshot of the > filesystem) and deallocate them in the live filesystem, a simple > operation given that it's guaranteed nothing will be using a block that > is both marked used and not assigned to anything. Thanks for that nutshell, CL. Sometimes little bits help the most <&^}=