Anton B. Rang writes: > It took manufacturers of SCSI drives some years to get this > right. Around 1997 or so we were still seeing drives at my former > employer that didn't properly flush their caches under all > circumstances (and had other "interesting" behaviours WRT caching). > > Lots of ATA disks never did bother to implement the write cache > controls. > > I haven't talked recently with any vendors who have been sourcing SATA > disks, so I don't know what they're seeing. Generally the major > players have their own disk qualification suites and often wind up > with custom firmware because they want all of their detected bugs > fixed before they'll accept a particular disk. If you buy a disk > off-the-shelf, you get a drive that's gone through the disk > manufacturer's testing (which is good, don't get me wrong) but hasn't > been qualified with the particular commands or configuration that a > particular operating system or file system might send. > > If you can do your own tests, that would be best; but that involves > executing a flush (with all the various combinations of commands > outstanding, dirty vs. clean cache buffers, etc.) and immediately > powering off the device, which generally can't be done without special > hardware. My *hunch* is that "enterprise-class" SATA disks have > probably gone through more of this sort of testing than consumer SATA, > even at the drive manufacturers. (It's not at all the same firmware.) > >
Much less scientific, but a quick and dirty way to flag some issues is by timing a few small O_DSYNC writes to an idle ZFS. If the flushes are ignored then latency will be anomalously low. -r > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
