From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 04:35:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 162281065688; Sat, 27 Sep 2008 04:35:04 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (h-74-0-89-210.lsanca54.covad.net [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id E26FE8FC1B; Sat, 27 Sep 2008 04:35:03 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from takeda.lan (takeda.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.2/8.14.2) with ESMTP id m8R4Z2RA061287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 21:35:02 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Fri, 26 Sep 2008 21:33:41 -0700 From: =?utf-8?Q?Derek_Kuli=C5=84ski?= X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <249873145.20080926213341@takeda.tk> To: Jeremy Chadwick In-Reply-To: <20080921220720.GA9847@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/8345/Fri Sep 26 18:20:01 2008 on chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2008 04:35:04 -0000 Hello Jeremy, Sunday, September 21, 2008, 3:07:20 PM, you wrote: > Consider using background_fsck="no" in /etc/rc.conf if you prefer the > old behaviour. Otherwise, boot single-user then do the fsck. Actually what's the advantage of having fsck run in background if it isn't capable of fixing things? Isn't it more dangerous to be it like that? i.e. administrator might not notice the problem; also filesystem could break even further... -- Best regards, Derek mailto:takeda@takeda.tk I tried to daydream, but my mind kept wandering.