On Fri, Oct 29, 2010 at 06:08:03PM +0200, Kevin Wolf wrote: > > I think we've got a bit of a problem. > > > > We have: > > > > 1) bdrv_flush() - sends an fdatasync > > > > 2) bdrv_aio_flush() - sends an fdatasync using the thread pool > > > > 3) qemu_aio_flush() - waits for all pending aio requests to complete > > > > But we use bdrv_aio_flush() to implement a barrier and we don't actually > > preserve those barrier semantics in the thread pool. > > Not really. We use it to implement flush commands, which I think don't > necessarily constitute a barrier by themselves.
Yes. Just as with normal disks qemu has absolutely no concept of I/O barriers. I/O barriers is an abstraction inside the Linux kernel that we fortunately finally got rid of. Qemu just gets a cache flush command from the guest and executes it. Usuaully asynchronously as synchronous block I/O with a single outstanding request is not very performant. The filesystem in the guest handles the ordering around it. > bdrv_aio_flush, as I understand it, is meant to flush only completed > writes. Exactly. The guest OS tracks writes and only issues a cache flush if all I/Os it wants to see flushes have been ACKed by the storage hardware / qemu.
