From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43238 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PLIgT-0003y9-TY for qemu-devel@nongnu.org; Wed, 24 Nov 2010 11:59:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PLIg6-0006oP-PP for qemu-devel@nongnu.org; Wed, 24 Nov 2010 11:59:01 -0500 Received: from verein.lst.de ([213.95.11.210]:45287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PLIg6-0006ni-Fm for qemu-devel@nongnu.org; Wed, 24 Nov 2010 11:58:42 -0500 Date: Wed, 24 Nov 2010 17:58:35 +0100 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk Message-ID: <20101124165835.GF31124@lst.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org I had the discussion with Jeremy in Boston before, but let's repeat it here: - is there actually any pre-existing xen backend that does properly implement empty barries. Back then we couldn't find any. - if this is a new concept to Xen please do not define an empty barrier primitive, but a new flush cache primitive. That one maps natively to the qemu I/O layer, and with recent Linux, NetBSD, Windows, or Solaris guest will be a lot faster than a barrier which drains the queue. Note that what your patch implements actually is a rather inefficient implementation of the latter. You do none of the queue draining which the in-kernel blkback implementation does by submitting the old-style barrier bio. While most filesystem do not care you introduce a quite subtile chance of data corruption for reiserfs, or ext4 with asynchronous journal commits on pre-2.6.37 kernels.