From owner-freebsd-alpha Sat Sep 26 15:33:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26329 for freebsd-alpha-outgoing; Sat, 26 Sep 1998 15:33:16 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26314 for ; Sat, 26 Sep 1998 15:33:10 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA22241; Sat, 26 Sep 1998 15:32:57 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd022201; Sat Sep 26 15:32:50 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA24181; Sat, 26 Sep 1998 15:32:45 -0700 (MST) From: Terry Lambert Message-Id: <199809262232.PAA24181@usr04.primenet.com> Subject: Re: one other thing... To: ken@plutotech.com (Kenneth D. Merry) Date: Sat, 26 Sep 1998 22:32:45 +0000 (GMT) Cc: freebsd-alpha@FreeBSD.ORG, gibbs@pluto.plutotech.com, imp@pluto.plutotech.com In-Reply-To: <199809260632.AAA09812@panzer.plutotech.com> from "Kenneth D. Merry" at Sep 26, 98 00:32:48 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Justin and I discovered that write caching was turned off on the 2gig > DEC OEM Barracudas that came with the Miata. Enabling write caching > improved performance a good bit. Be careful with this. This is intentional. Enabling caching will make the disk respond that it has committed the write to stable storage, when it fact it has not. If you do not get power fail notification of some kind, then there is no way to guarantee that your disk can be recovered to the state that it was supposed to be in (as opposed to merely being recovered to a consistent state). It is much better to turn *off* write caching, and use soft updates (which also, technically, does it's own write caching), rather than enabling it on the drive. An example of where this might screw the pooch for you is if you had a database and an index file, and you wrote the new record out, then wrote the modified index pointing to the new record instead of the old, and then lost power. The drive, in doing caching, may reorder these operations, such that the index is written out, but the new record is not. The normal way you guarantee ordering in an application is to fsync() the record file before writing the index. The fsync() is not supposed to return until the drive states the data has been committed to stable storage. With write caching on, the drive lies. PS: If you turn this on, you might as well mount the drive async, too, since we are only talking about "how the data can not be trusted", as opposed to "if the data can not be trusted" (it can't). If you get power fail notification, then you can use async and drive level write caching in relative saftey (ie: as safe as possible, given the possibility of the system crashing for some reason other than power failure). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message