From patchwork Wed May 13 01:52:17 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rusty Russell X-Patchwork-Id: 23425 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n4D1r8kj012512 for ; Wed, 13 May 2009 01:53:08 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752307AbZEMBwc (ORCPT ); Tue, 12 May 2009 21:52:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752665AbZEMBwb (ORCPT ); Tue, 12 May 2009 21:52:31 -0400 Received: from ozlabs.org ([203.10.76.45]:41319 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752256AbZEMBwa (ORCPT ); Tue, 12 May 2009 21:52:30 -0400 Received: from vivaldi.localnet (unknown [150.101.102.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPSA id 46F21DDFB2; Wed, 13 May 2009 11:52:31 +1000 (EST) From: Rusty Russell To: Christian Borntraeger Subject: Re: [PATCH, RFC] virtio_blk: add cache flush command Date: Wed, 13 May 2009 11:22:17 +0930 User-Agent: KMail/1.11.2 (Linux/2.6.28-11-generic; KDE/4.2.2; i686; ; ) Cc: Christoph Hellwig , kvm@vger.kernel.org References: <20090511083908.GB20082@lst.de> <200905122324.14970.rusty@rustcorp.com.au> <200905121618.36104.borntraeger@de.ibm.com> In-Reply-To: <200905121618.36104.borntraeger@de.ibm.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200905131122.18221.rusty@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 12 May 2009 11:48:36 pm Christian Borntraeger wrote: > Am Tuesday 12 May 2009 15:54:14 schrieb Rusty Russell: > > On Mon, 11 May 2009 06:09:08 pm Christoph Hellwig wrote: > > > Do we need a new feature flag for this command or can we expect that > > > all previous barrier support was buggy enough anyway? > > > > You mean reuse the VIRTIO_BLK_F_BARRIER for this as well? Seems fine. > > It is also used by kuli > (http://www.ibm.com/developerworks/linux/linux390/kuli.html) and kuli used > fdatasync. OK, that's sufficient for me. It's not like block is going to catch up with net for feature flags any time soon. Christoph, please make a new feature flag. Oh and FYI Christian, you might not have seen this patch: lguest: barrier me harder Impact: barrier correctness in example launcher I doubt either lguest user will complain about performance. Reported-by: Christoph Hellwig Cc: Jens Axboe Signed-off-by: Rusty Russell --- Documentation/lguest/lguest.c | 7 +++++++ 1 file changed, 7 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c @@ -1630,6 +1630,13 @@ static bool service_io(struct device *de } } + /* OK, so we noted that it was pretty poor to use an fdatasync as a + * barrier. But Christoph Hellwig points out that we need a sync + * *afterwards* as well: "Barriers specify no reordering to the front + * or the back." And Jens Axboe confirmed it, so here we are: */ + if (out->type & VIRTIO_BLK_T_BARRIER) + fdatasync(vblk->fd); + /* We can't trigger an IRQ, because we're not the Launcher. It does * that when we tell it we're done. */ add_used(dev->vq, head, wlen);