From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 08:04:02 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 5305D106569E for ; Sat, 27 Sep 2008 08:04:02 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id D2C768FC1B for ; Sat, 27 Sep 2008 08:04:01 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:50304 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1KjUXw-0001Dq-4b for freebsd-stable@FreeBSD.org; Sat, 27 Sep 2008 09:48:56 +0200 Received: (qmail 68452 invoked from network); 27 Sep 2008 09:48:53 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 27 Sep 2008 09:48:53 +0200 Received: (qmail 64448 invoked by uid 1001); 27 Sep 2008 09:48:53 +0200 Date: Sat, 27 Sep 2008 09:48:53 +0200 From: Erik Trulsson To: Jeremy Chadwick Message-ID: <20080927074853.GA64298@owl.midgard.homeip.net> 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> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080927064417.GA43638@icarus.home.lan> User-Agent: Mutt/1.5.18 (2008-05-17) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1KjUXw-0001Dq-4b. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1KjUXw-0001Dq-4b d7c47301fa55f3ccaf9b0cebdb1a7901 Cc: Derek Kuli??ski , 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 08:04:02 -0000 On Fri, Sep 26, 2008 at 11:44:17PM -0700, Jeremy Chadwick wrote: > On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote: > > 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) > > Re: write caching: wheelies and burn-outs in empty parking lots > detected. > > Let's be realistic. We're talking about ATA and SATA hard disks, hooked > up to on-board controllers -- these are the majority of users. Those > with ATA/SATA RAID controllers (not on-board RAID either; most/all of > those do not let you disable drive write caching) *might* have a RAID > BIOS menu item for disabling said feature. > > FreeBSD atacontrol does not let you toggle such features (although "cap" > will show you if feature is available and if it's enabled or not). No, but using 'sysctl hw.ata.wc=0' will quickly and easily let you disable write caching on all ATA/SATA devices. This was actually the default setting briefly (back in 4.3 IIRC) but was reverted due to the performance penalty being considered too severe. > > Users using SCSI will most definitely have the ability to disable > said feature (either via SCSI BIOS or via camcontrol). But the majority > of users are not using SCSI disks, because the majority of users are not > going to spend hundreds of dollars on a controller followed by hundreds > of dollars for a small (~74GB) disk. > > Regardless of all of this, end-users should, in no way shape or form, > be expected to go to great lengths to disable their disk's write cache. > They will not, I can assure you. Thus, we must assume: write caching > on a disk will be enabled, period. If a filesystem is engineered with > that fact ignored, then the filesystem is either 1) worthless, or 2) > serves a very niche purpose and should not be the default filesystem. > > Do we agree? Sort of, but soft updates does not technically need write caching to be disabled. It does assume that disks will not 'lie' about if data has actually been written to the disk or just to the disk's cache. Many (most?) ATA/SATA disks are unreliable in this regard which means that the guarantees Soft Updates normally give about consistency of the file system can no longer be guaranteed. Using UFS2+soft updates on standard ATA/SATA disks (with write caching enabled) connected to a standard disk controller is not a problem (not any more than any other file system anyway.) Using background fsck together with the above setup is not recommended however. Background fsck will only handle a subset of the errors that a standard foreground fsck can handle. In particular it assumes that the soft updates guarantees of consistency are in place which would mean that there are only a few non-critical problems that could happen. With the above setup those guarantees are not in place, which means that background fsck can encounter errors it cannot (and will not) fix. -- Erik Trulsson ertr1013@student.uu.se