Christoph Hellwig wrote:
On Mon, May 11, 2009 at 07:49:37PM +0300, Avi Kivity wrote:
Maybe we should add a fourth cache= mode then. But
cache=writeback+fsync doesn't correspond to any real world drive; in the
real world you're limited to power failures and a few megabytes of cache
(typically less), cache=writeback+fsync can lose hundreds of megabytes
due to power loss or software failure.
cache=writeback+fsync is exactly the same model as a normal writeback
cache disk drive. (Well, almost as we currently don't use tag ordering
but drain flushes as a Linux implementation detail, but the disks also
support TCQ-based ordering).
The cache size on disks is constantly growing, and if you lose cache
it doesn't really matter how much you lose but what you lose.
Software errors won't cause data loss on a real disk (firmware bugs
will, but the firmware is less likely to crash than the host OS).
Oh, and cache=writeback+fsync doesn't work on qcow2, unless we add fsync
after metadata updates.
If you care about data integrity in case of crashes qcow2 doesn't work
at all.
Do you known of any known corruptors in qcow2 with cache=writethrough?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
