Michael Favinsky wrote:
> I understand async is always unsafe. I don't mean async. I don't use async.
>
> I mean the hardware write cache built into the ATA drives. I read somewhere
Funny...I've read lots of things that proved to be wrong.
Wrote a few things, too. ;)
> that, unlike SCSI drives, the write cache in ATA drives results in
> misinformation about when data was actually written to disk. So, as I
> understand it, you can't use soft updates with the drive's write cache on.
> So you have to chose between the drive's write cache or using soft updates.
eh. I'm not impressed by this argument.
Most thinking along these lines seems to expect that individual sectors
are successfully written or not written to disk ("what if this gets
written but that doesn't?"), and worry about the file system's integrity
based on that. Reality is a little more complicated -- the world
doesn't plan power outages or communications problems for the times
between when the disk isn't being written to. Interrupt a disk
mid-write, the sector(s) under the head are hosed, the data in them is
lost. Caching (or not caching) will not save you, IDE vs. SCSI will not
save you. There are things they can try to do in the design to minimize
this impact (have enough capacitance on-board to finish writing a sector
when the power goes out, and detect that and not try to start the next
write), but I'd not bet they would always save your data or your butt.
That's for a power outage. If you are worried about a SW crash,
whatever got sent to the drive (and is thus in cache) should make it out
to disk eventually. Maybe.
Personally, I don't ever turn off the write caching. I almost always
use softdeps. I have only a few machines attached to UPSs. I don't
always use the "halt" command before power down if it is inconvenient
(Yes, I abuse the things to find out what happens and what I need to do
when the unexpected happens). I've never lost one of my own file
systems doing this out of the hundreds of machines I've probably abused
this way. I've had a couple "events" at clients which were apparently
triggered by power outages, one resulted in bad sectors on the hard
disk, preventing a proper fsck (however, a mount -f got the system
on-line, tar'd up the files without any error message, replaced the
drive and was back up and running in short order). Had a few hard disks
outright fail, maybe power event related, maybe not.
For all the claimed wonder about SCSI drives and the foolishness of IDE
caching, I had one SCSI drive blow out the entire file system when the
SCSI adapter fell out of the computer (I was having a bad day, m'kay?).
No power interruption to the drive, just a sudden and nasty
interruption of communications from the drive to the interface. Never
saw an IDE drive trash a file system that bad and still have the drive
working.
You are worried about tiny little things that very rarely happen in real
life. Kinda like worrying about being struck by lightning while playing
in the middle of a superhighway -- could happen, but if you made this
risk scenareo completely vanish, on the average, it would not change
your life one bit.
If you REALLY want to obsess about that possible lighting strike and
really believe your assessment is correct, do your own benchmarks for
your own application(s), and answer your own question for your own usage.
Nick.
