Re: [Qemu-devel] [PATCH] bdrv_aio_flush

[Jens Axboe <qemu@kernel.dk>]

On Tue, Sep 02 2008, Ian Jackson wrote:
> Andrea Arcangeli writes ("Re: [Qemu-devel] [PATCH] bdrv_aio_flush"):
> > In case you meant fsync is just fine, Linux will use the
> > WIN_FLUSH_CACHE/WIN_FLUSH_CACHE_EXT see
> > idedisk_prepare_flush:
> > 
> >                  if (barrier) {
> >                       ordered = QUEUE_ORDERED_DRAIN_FLUSH;
> >                       prep_fn = idedisk_prepare_flush;
> >                  }
> 
> I'm not sure I follow but I'm not familiar with the relevant Linux
> code.  Do you mean that Linux does this
> 
>     submit IO 1 to device
>     submit flush to device
>     collect IO 1 completion
>     collect flush completion
> 
> and then expects IO 1 to be on disk ?

Given that this case refers to PATA/SATA and that you can't queue the
flush operation, it looks something like:

        submit IO 1 to device
        IO 1 completes
        submit flush
        flush completes

and at this point, flush completion either ends in error (in which case
we can't rely on IO 1 being safely stored), or it suceeds and Linux then
expects IO 1 to be on disk. If it isn't, then the device is broken (as
simple as that).

> If this is a documented behaviour of the controller or device we're
> emulating then I think the qemu emulation (hw/scsi-disk.c or whatever)
> should do an aio_flush barrier before aio_fsync.

Certainly it is, when the flush command returns, all dirty drive cache
must be safely on platter.

> What spec should I be referring to ?

ata spec, see t13.org

> Perhaps I'm naive but I would expect the device interface to look more
> like the kernel syscall interface, whose specification text (in SuSv3)
> I analysed in April in
>  http://lists.nongnu.org/archive/html/qemu-devel/2008-04/msg00046.html
> 
> Ian.
> 
> 

-- 
Jens Axboe