Re: [Qemu-devel] [PATCH] bdrv_aio_flush

[Ian Jackson]

Jens Axboe writes ("Re: [Qemu-devel] [PATCH] bdrv_aio_flush"):
> On Tue, Sep 02 2008, Ian Jackson wrote:
> > This is still not perfect because we unnecessarily flush some data
> > thus delaying reporting completion of the WRITE FUA.  But there is at
> > at least no need to wait for _other_ writes to complete.
> 
> I don't see how the above works. There's no dependency on FUA and
> non-FUA writes, in fact FUA writes tend to jump the device queue due to
> certain other operating systems using it for conditions where that is
> appropriate. So unless you do all writes using FUA, there's no way
> around a flush for committing dirty data. Unfortunately we don't have a
> FLUSH_RANGE command, it's just a big sledge hammer.

Yes, certainly you do aio_sync _some_ data that doesn't need to be.
Without an O_FSYNC flag on aio_write that's almost inevitable.

But if bdrv_aio_fsync also does a flush first then you're going to
sync _even more_ unnecessarily: the difference between `bdrv_aio_fsync
does flush first' and `bdrv_aio_fsync does not flush' only affects
writes are queued but not completed when bdrv_aio_fsync is called.

That is, non-FUA writes which were submitted after the FUA write.
There is no need to fsync these and that's what I think qemu should
do.

Andrea was making some comments about scsi and virtio.  It's possible
that these have different intended semantics and perhaps those device
models (in hw/*) need to call flush explicitly before sync.

Ian.