From owner-freebsd-current@FreeBSD.ORG Sun Mar 30 09:59:28 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9386437B423 for ; Sun, 30 Mar 2003 09:59:28 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F04E43F85 for ; Sun, 30 Mar 2003 09:59:22 -0800 (PST) (envelope-from das@FreeBSD.org) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h2T055ah022203; Fri, 28 Mar 2003 16:05:05 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h2T055xO022202; Fri, 28 Mar 2003 16:05:05 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Fri, 28 Mar 2003 16:05:05 -0800 From: David Schultz To: Alexander Langer Message-ID: <20030329000505.GB22044@HAL9000.homeunix.com> Mail-Followup-To: Alexander Langer , current@FreeBSD.ORG References: <20030324215712.GA844@fump.kawo2.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030324215712.GA844@fump.kawo2.rwth-aachen.de> cc: current@FreeBSD.org Subject: Re: several background fsck panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 17:59:30 -0000 Thus spake Alexander Langer : > I had several panics related to background fsck now. Once I disabled > background fsck, all went ok. > > It began when I pressed the reset buttons on several boots while the > system was still doing fscks. [...] > Mar 24 21:48:59 fump kernel: panic: ufs_dirbad: bad dir You would have gotten this one without bgfsck as well the next time you tried to look the offending directory. Background fsck only expedited the panic by reading all the directories on the system in order to perform its checks. Basically, the panic is the kernel's way of telling you that something is unexpectedly wrong with the filesystem (due in this case to ATA write caching), and that it is going to give up rather than risk causing further damage. UFS, as well as most other filesystems, are not designed to tolerate failures on the part of the hardware to honor its guarantees, so it's hard to do better without inventing a new filesystem.