From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 16:46:17 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 71595106569E for ; Sat, 27 Sep 2008 16:46:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id E2B048FC17 for ; Sat, 27 Sep 2008 16:46:16 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m8RGkEar075242; Sat, 27 Sep 2008 18:46:15 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m8RGkEIt075241; Sat, 27 Sep 2008 18:46:14 +0200 (CEST) (envelope-from olli) Date: Sat, 27 Sep 2008 18:46:14 +0200 (CEST) Message-Id: <200809271646.m8RGkEIt075241@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20080927.100458.74661341.sthaug@nethelp.no> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sat, 27 Sep 2008 18:46:15 +0200 (CEST) Cc: Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG 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 16:46:17 -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. Just a "me too" here. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal