[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] bdrv_aio_flush
From: |
Jens Axboe |
Subject: |
Re: [Qemu-devel] [PATCH] bdrv_aio_flush |
Date: |
Tue, 2 Sep 2008 16:25:24 +0200 |
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