Re: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk

[Rik van Riel <riel@redhat.com>]

Paul Brook wrote:
>>> With a proper async API, is there any reason why we would want this to be
>>> tunable?  I don't think there's much of a benefit of prematurely claiming
>>> a write is complete especially once the SCSI emulation can support
>>> multiple simultaneous requests.
>> You're right.  This O_SYNC bandaid should probably stay in place
>> to prevent data corruption, until the AIO framework is ready to
>> be used.
> 
> It's arguable whether O_SYNC is needed at all. Qemu doesn't claim data is 
> written to disk, and provides facilities for the guest OS to flush the cache, 
> just like real hardware does.

Nice.  Another difference between the qemu codebase and the qemu-dm
codebase used by Xen.

With the bdrv_flush stuff in place, it should even be easy for qemu
to actually do something when the guest OS switches disk write caching
off (currently that is a noop in the qemu code base).

> Have you measured the impact of O_SYNC? I wouldn't be surprised if it was 
> significant.

I suspect it'll be horrific in the qemu codebase (blocking execution
of the guest OS until disk IO is complete), but it's fine in the Xen
qemu-dm situation, where IO completion happens asynchronously.

The recent commit message on the Xen side did not suggest there was
that much of a difference between both qemu code bases.  Obviously
I was wrong, and the O_SYNC bandaid should probably be kept out for
now.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan