No you can't. Suppose you send a bunch of raw writes to a SCSI disk drive.
OK, so the SCSI disk drive queues them in its embedded cache RAM and tells
the host CPU to send more data. Then the power fails before the SCSI drive
can flush its embedded cache.
Oops.
The software (kernel or application or system configuration/install
program) has to know how to tell the drive that it is not to use its
write cache *at all*, or if it is to use it, to use it to perform writes
in *strict* compliance with the order given, and to *not* acknowledge
anything until all writes have been completed. And of course those
settings had better not vanish if the SCSI bus is reset due to say heat
problems.
There's the possibility of external RAID devices that will undo all that
work for you by doing buffering and ACK's by themselves, then turning
around to talk to disks with data in cache.
Some of the more exotic storage types will actually put several disk
blocks in jeopardy when rewriting only one or two, in the name of
enhanced error correction capability or some such thing. If the kernel
orders a 512-byte sector to be updated to the hardware, will the drive
overwrite only that sector, or will it rewrite the entire track with
new Reed-Solomon codes or some such thing? In other words, if the power
fails, is one sector trashed or an entire cylinder?
And of course we assume here that the disk won't lose its marbles if
hardware failure occurs during write; what if a power problem starts a head
moving across the disk platter with the write head engaged?
Oops.
I won't mention hard disk firmware bugs. <shiver> Let's not go there.
Assuming you can herd these cats, then everything you say is true.
But that's a big assumption and it's not something you can say without
carefully reading the labels on all the boxes. Raw disk I/O is probably
necessary but definitely not sufficient.
-- Zygo Blaxell (with a name like that, who needs a nick?) Linux Engineer (my favorite official job title so far) Corel Corporation (whose opinions sometimes differ from those shown above) zygob@corel.ca (also zblaxell@furryterror.org)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/