Hello, my understanding is that ZFS is specifically designed to work with write caching, by instructing drives to flush their caches when a write barrier is needed. And in fact, even turns write caching on explicitly on managed devices. My question is of a practical nature: will this *actually* be safe on the average consumer grade SATA drive? I have seen offhand references to PATA drives generally not being trustworthy when it comes to this (SCSI therefore being recommended), but I have not been able to find information on the status of typical SATA drives. While I do intend to perform actual powerloss tests, it would be interesting to hear from anybody whether it is generally expected to be safe. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' Key retrieval: Send an E-Mail to getpgpkey at scode.org E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org
Hello Peter,
Tuesday, December 12, 2006, 11:18:32 PM, you wrote:
PS> Hello,
PS> my understanding is that ZFS is specifically designed to work with write
PS> caching, by instructing drives to flush their caches when a write barrier
is
PS> needed. And in fact, even turns write caching on explicitly on managed
PS> devices.
PS> My question is of a practical nature: will this *actually* be safe on the
PS> average consumer grade SATA drive? I have seen offhand references to PATA
PS> drives generally not being trustworthy when it comes to this (SCSI
therefore
PS> being recommended), but I have not been able to find information on the
PS> status of typical SATA drives.
PS> While I do intend to perform actual powerloss tests, it would be
interesting
PS> to hear from anybody whether it is generally expected to be safe.
Well is disks honors cache flush commands then it should be reliable
wether it''s SATA or SCSI disk.
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
> PS> While I do intend to perform actual powerloss tests, it would be > interesting PS> to hear from anybody whether it is generally expected to be > safe. > > Well is disks honors cache flush commands then it should be reliable > wether it''s SATA or SCSI disk.Yes. Sorry, I could have stated my question clear:er. What I am specifically concerned about is exactly that - whether your typical SATA drive *will* honor cache flush commands, as I understand a lot of PATA drives did/do not. Googling tends to give very little concrete information on this since very few people actually seem to care about this. Since I wanted to confirm my understanding of ZFS semantics w.r.t. write caching anyway I thought I might aswell also ask about the general tendency among drives since, if anywhere, people here might know. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' Key retrieval: Send an E-Mail to getpgpkey at scode.org E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org
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.) This message posted from opensolaris.org
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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss