Rik van Riel wrote:
> This may look like hair splitting, but so far I've lost a
> (test) postgresql database to this 3 times already. Not getting
> the guest application's data to disk when the application calls
> fsync is a recipe for disaster.
Exactly the same thing happens with real IDE disks if IDE write
caching (on the drive itself) is enabled, which it is by default. It
is rarer, but it happens.
I've seen this with Linux 2.4 kernels writing to ext3 (real, not
virtual). Filesystem metadata gets corrupted from time to time if
power is removed, because write ordering is not preserved. Disabling
IDE write caching fixes it, but the performance impact is huge on some
systems.
Linux 2.6 kernels will issue IDE cache flush commands, at least with
ext3, to commit data to disk when fsync is called, and to preserve
journal/metadata ordering.
Doesn't qemu fsync the host file corresponding to the emulated disk,
when the guest OS issues an IDE cache flush?
For IDE emulation to be as reliable for data storage as a real disk,
it should:
- fsync the host file whenever the guest OS issues an IDE cache
flush command.
- use O_SYNC (or fsync after each write or aio equivalent, etc.) _only_
when the guest OS disables the IDE disk cache (not done by default).
-- JAmie
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
