From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 05:36:06 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 CD42D1065686; Sat, 27 Sep 2008 05:36:06 +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 844548FC16; Sat, 27 Sep 2008 05:36:06 +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 m8R5a5ZW062047 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 22:36:05 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Fri, 26 Sep 2008 22:35:57 -0700 From: =?utf-8?Q?Derek_Kuli=C5=84ski?= X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <765067435.20080926223557@takeda.tk> To: Jeremy Chadwick In-Reply-To: <20080927051413.GA42700@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@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 05:36:06 -0000 Hello Jeremy, Friday, September 26, 2008, 10:14:13 PM, you wrote: >> 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... > This question should really be directed at a set of different folks, > e.g. actual developers of said stuff (UFS2 and soft updates in > specific), because it's opening up a can of worms. > I believe it has to do with the fact that there is much faith given to > UFS2 soft updates -- the ability to background fsck allows the user to > boot their system and have it up and working (able to log in, etc.) in a > much shorter amount of time[1]. It makes the assumption that "everything > will work just fine", which is faulty. As far as I know (at least ideally, when write caching is disabled) the data should always be consistent, and all fsck supposed to be doing is to free unreferenced blocks that were allocated. Wouldn't be possible for background fsck to do that while the filesystem is mounted, and if there's some unrepairable error, that somehow happen (while in theory it should be impossible) just periodically scream on the emergency log level? > It also gives the impression of a journalled filesystem, which UFS2 soft > updates are not. gjournal(8) on the other hand, is, and doesn't require > fsck at all[2]. > I also think this further adds fuel to the "so why are we enabling soft > updates by default and using UFS2 as a filesystem again?" fire. I'm > sure someone will respond to this with "So use ZFS and shut up". *sigh* I think the reason for using Soft Updates by default is that it was a pretty hard thing to implement, and (at least in theory it supposed by as reliable as journaling. Also, if I remember correctly, PJD said that gjournal is performing much better with small files, while softupdates is faster with big ones. -- Best regards, Derek mailto:takeda@takeda.tk Programmers are tools for converting caffeine into code.