From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=44690 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PCBRQ-0003vn-6R
	for qemu-devel@nongnu.org; Sat, 30 Oct 2010 09:25:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1PCBRO-0007zx-Dp
	for qemu-devel@nongnu.org; Sat, 30 Oct 2010 09:25:52 -0400
Received: from verein.lst.de ([213.95.11.210]:41910)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1PCBRO-0007zB-1r
	for qemu-devel@nongnu.org; Sat, 30 Oct 2010 09:25:50 -0400
Date: Sat, 30 Oct 2010 15:25:33 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 2/3] v2 Fix Block Hotplug race with
	drive_unplug()
Message-ID: <20101030132533.GA29943@lst.de>
References: <1288030956-28383-1-git-send-email-ryanh@us.ibm.com>
	<1288030956-28383-3-git-send-email-ryanh@us.ibm.com>
	<m34oc5ksia.fsf@blackfin.pond.sub.org>
	<4CCAD6F4.6010201@linux.vnet.ibm.com> <4CCADA4C.4030302@redhat.com>
	<4CCADCF9.5030508@linux.vnet.ibm.com> <4CCAE0E0.7020707@redhat.com>
	<4CCAE803.8090800@linux.vnet.ibm.com> <4CCAF163.1090806@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4CCAF163.1090806@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org, Anthony Liguori <aliguori@linux.vnet.ibm.com>, Ryan Harper <ryanh@us.ibm.com>, Stefan Hajnoczi <stefan.hajnoczi@uk.ibm.com>, Christoph Hellwig <hch@lst.de>

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.