From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH, RFC] virtio_blk: add cache flush command Date: Mon, 18 May 2009 14:07:02 +0200 Message-ID: <20090518120702.GD11112@lst.de> References: <20090511083908.GB20082@lst.de> <200905122324.14970.rusty@rustcorp.com.au> <200905121618.36104.borntraeger@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Rusty Russell , Christoph Hellwig , kvm@vger.kernel.org To: Christian Borntraeger Return-path: Received: from verein.lst.de ([213.95.11.210]:36395 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755674AbZERMHI (ORCPT ); Mon, 18 May 2009 08:07:08 -0400 Content-Disposition: inline In-Reply-To: <200905121618.36104.borntraeger@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, May 12, 2009 at 04:18:36PM +0200, 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. > > > > AFAIK only lguest offered that, and lguest has no ABI. Best would be to > > implement VIRTIO_BLK_T_FLUSH as well; it's supposed to be demo code, and it > > should be easy). > > It is also used by kuli (http://www.ibm.com/developerworks/linux/linux390/kuli.html) > and kuli used fdatasync. Since kuli is on offical webpages it takes a while > to update that code. When you reuse the VIRTIO_BLK_F_BARRIER flag, that would > trigger some VIRTIO_BLK_T_FLUSH commands sent to the kuli host, right? > I think the if/else logic of kuli would interpret that as a read request....I > am voting for a new feature flag :-) Ok, next version will have a new feature flag. I actually have some other bits I want to redesign so it might take a bit longer to get it out.