Date: Sat, 27 Sep 2008 09:48:53 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: Derek Kuli??ski <takeda@takeda.tk>, freebsd-stable@FreeBSD.org, Clint Olsen <clint.olsen@gmail.com> Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY Message-ID: <20080927074853.GA64298@owl.midgard.homeip.net> In-Reply-To: <20080927064417.GA43638@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> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080927074853.GA64298>