Re: [PERFORM] Arguments Pro/Contra Software Raid

On May 9, 2006, at 11:26 AM, Joshua D. Drake wrote:
> Of course not, but which drives lie about sync that are SATA? Or more
> specifically SATA-II?

With older Linux drivers (before spring 2005, I think) - all of
them - since it seems the linux kernel didn't support the
write barriers needed to force the sync. It's not clear to
me how much of the SATA data loss is due to this driver issue
and how much is due to buggy drives themselves.

According to Jeff Garzik (the guy who wrote the SATA drivers
for Linux) [1]

"You need a vaguely recent 2.6.x kernel to support fsync(2)
and fdatasync(2) flushing your disk's write cache.
Previous 2.4.x and 2.6.x kernels would only flush the write
cache upon reboot, or if you used a custom app to issue
the 'flush cache' command directly to your disk.

Very recent 2.6.x kernels include write barrier support, which
flushes the write cache when the ext3 journal gets flushed to disk.

If your kernel doesn't flush the write cache, then obviously there
is a window where you can lose data. Welcome to the world of
write-back caching, circa 1990.

If you are stuck without a kernel that issues the FLUSH CACHE (IDE)
or SYNCHRONIZE CACHE (SCSI) command, it is trivial to write
a userspace utility that issues the command.

Jeff, the Linux SATA driver guy
"

I've wondered for a while if this driver issue is actually the
source of most of the fear around SATA drives. Note it appears
that with those old kernels you aren't that safe with SCSI either.

[1] in may 2005, http://hardware.slashdot.org/comments.pl?sid=149349&cid=12519114