Date: Sat, 26 Sep 1998 22:32:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ken@plutotech.com (Kenneth D. Merry) Cc: freebsd-alpha@FreeBSD.ORG, gibbs@pluto.plutotech.com, imp@pluto.plutotech.com Subject: Re: one other thing... Message-ID: <199809262232.PAA24181@usr04.primenet.com> In-Reply-To: <199809260632.AAA09812@panzer.plutotech.com> from "Kenneth D. Merry" at Sep 26, 98 00:32:48 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809262232.PAA24181>