Date: Sat, 26 Sep 1998 17:00:38 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Terry Lambert <tlambert@primenet.com> Cc: ken@plutotech.com (Kenneth D. Merry), freebsd-alpha@FreeBSD.ORG, gibbs@plutotech.com, imp@plutotech.com Subject: Re: one other thing... Message-ID: <199809262307.RAA14553@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 26 Sep 1998 22:32:45 -0000." <199809262232.PAA24181@usr04.primenet.com>
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. Really? I didn't know that the write cache had that effect. Fascinating. >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). Although I've never seen this happen on any of the disks I have here, yes, it could happen. The chances of it happening, due to the small size of the cache on most disks, the fact that most drives will commit the write to non-volatile storage as soon as possible, etc. make your chances pretty good. Certainly better than if you were running async mounts. >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. My systems don't usually panic. Why? I don't use soft updates, yet. Soft Updates is not a replacement for the on disk cache. The two serve very different purposes. One reduces the number of writes to the device, the other reduces the number of writes committed by the device to the disk and reduces latency for any device writes that the OS believes are necessary. >The drive, in doing caching, may reorder these operations, such >that the index is written out, but the new record is not. This all depends on how you setup the drive. You can tell it not to re-order writes (FSW bit in the caching control page). If I was really worried, however, I'd have the box on a UPS. >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. This is an interface issue, not a cache issue. If the kernel told the disk driver to sync the cache, it could. This is what the Synchronize Cache command is all about. >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). You are assuming that the OS will never panic. I don't use async mounts because I expect the OS to occasionally crash. I worry about power outages too, but they are something I can easily control with a UPS. >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). exactly. So why did you feel the need to sermonize again? Ken and I are well aware of how SCSI devices work and the effects of setting these parameters. We did write a SCSI layer, you know... -- Justin 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?199809262307.RAA14553>