From owner-freebsd-questions@FreeBSD.ORG Sun Sep 12 21:34:19 2010 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 F119F106564A for ; Sun, 12 Sep 2010 21:34:19 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from woodbine.london.02.net (woodbine.london.02.net [87.194.255.145]) by mx1.freebsd.org (Postfix) with ESMTP id 912478FC0A for ; Sun, 12 Sep 2010 21:34:19 +0000 (UTC) Received: from unknown (94.193.93.212) by woodbine.london.02.net (8.5.124.10) id 4C886ABA0018F791; Sun, 12 Sep 2010 22:34:10 +0100 Date: Sun, 12 Sep 2010 22:34:06 +0100 From: Bruce Cran To: Robert Bonomi Message-ID: <20100912223406.00005904@unknown> In-Reply-To: <201009122116.o8CLGr0l016533@mail.r-bonomi.com> References: <201009122116.o8CLGr0l016533@mail.r-bonomi.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: cronfy@gmail.com, freebsd-questions@freebsd.org Subject: Re: fsck reports errors on clean filesystem (mounted rw) 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: Sun, 12 Sep 2010 21:34:20 -0000 On Sun, 12 Sep 2010 16:16:53 -0500 (CDT) Robert Bonomi wrote: > There are exactly _four_ possible causes of file-system > inconsistencies. 1) You can have an unexpected loss of power, where > the CPU stops working before it as time to write the above-mentioned > 'memory-resident' data to disk. There are sub-classes of tis event, > to distinguish between A utility company outage, somebody > accidentally 'pulling the plug', be it litterally, or the power > on/off switch, and somebody itting the 'reset' button. They all ave > te same effect, the processor can't get te 'current' data in memory > out to the disk. 2) you can hve a catastropic O/S failure -- a system > 'crash' -- were the O/S has discovered an internal inconsistency. > _IT_ doesn't trust its own data enough to keep running, and takes > 'the lesser of two evils' route of *not* writing "known to be > suspect" data over the out-of-date data on the disk. > 3) 'bit rot' on the phyiscal media itself. Where what gets read > back is *not* what was written there earlier. Modern disk drives > detect this inside the controller and use embedded ECC info to give > the 'right' data back, while alerting that the problem exists. > 4) "Hardware failures" of any of a variety of sorts -- flakey power > supply, bad RAM memory, failing controller cipes, etc. 5. An bug in the filesystem code. I've been seeing UFS corruption in recently -current, as have others, which isn't associated with crashes or bad media. -- Bruce Cran