From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 13:31:05 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 75A8F1065688 for ; Mon, 29 Sep 2008 13:31:05 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 337588FC08 for ; Mon, 29 Sep 2008 13:31:04 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 731A919E02A; Mon, 29 Sep 2008 15:31:03 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 658D019E027; Mon, 29 Sep 2008 15:31:01 +0200 (CEST) Message-ID: <48E0D8B7.4010502@quip.cz> Date: Mon, 29 Sep 2008 15:31:35 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: sthaug@nethelp.no References: <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <20080927.100458.74661341.sthaug@nethelp.no> In-Reply-To: <20080927.100458.74661341.sthaug@nethelp.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org 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: Mon, 29 Sep 2008 13:31:05 -0000 sthaug@nethelp.no wrote: >>>IMHO, a dirty filesystem should not be mounted until it's been fully >>>analysed/scanned by fsck. So again, people are putting faith into >>>UFS2+SU despite actual evidence proving that it doesn't handle all >>>scenarios. >> >>Yes, I think the background fsck should be disabled by default, with a >>possibility to enable it if the user is sure that nothing will >>interfere with soft updates. > > > Having been bitten by problems in this area more than once, I now always > disable background fsck. Having it disabled by default has my vote too. Is there any possibility to selectively disable / enable background fsck on specified mount points? I can imagine system, where root, /usr, /var and /tmp will be checked by fsck in foreground, but waiting to foreground fsck on data partitions of about 500GB or more (it can take up tens of minutes or "hours") is scary. I need server with ssh running up "quickly" after the crash, so I can investigate what the problem was and not just sit and wait tens of minutes "if" machine gets online again or not... answering phone calls of clients in the meantime. Miroslav Lachman