From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: Notes on block I/O data integrity Date: Fri, 28 Aug 2009 11:33:59 +0930 Message-ID: <200908281133.59982.rusty@rustcorp.com.au> References: <20090825181120.GA4863@lst.de> <200908272021.56219.rusty@rustcorp.com.au> <20090827134239.GA13479@lst.de> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Christoph Hellwig Return-path: Received: from ozlabs.org ([203.10.76.45]:56708 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751061AbZH1CEA (ORCPT ); Thu, 27 Aug 2009 22:04:00 -0400 In-Reply-To: <20090827134239.GA13479@lst.de> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 27 Aug 2009 11:12:39 pm Christoph Hellwig wrote: > On Thu, Aug 27, 2009 at 08:21:55PM +0930, Rusty Russell wrote: > > > - virtio-blk needs to advertise ordered queue by default. > > > This makes cache=writethrough safe on virtio. > > > > >From a guest POV, that's "we don't know, let's say we're ordered because that > > may make us safer". Of course, it may not help: how much does it cost to > > drain the queue? > > > > The bug, IMHO is that we *should* know. And in future I'd like to fix that, > > either by adding an VIRTIO_BLK_F_ORDERED feature, or a VIRTIO_BLK_F_UNORDERED > > feature. > > > > > Action plan for QEMU: > > > > > > - IDE needs to set the write cache enabled bit > > > - virtio needs to implement a cache flush command and advertise it > > > (also needs a small change to the host driver) > > > > So, virtio-blk needs to be enhanced for this as well. > > Really, enabling volatile write caches without advertising a cache flush > command is a bug in the storage, where in our case qemu is the storage. > So I don't really see the need for two feature bits. Here's my plan for > virtio-blk: > > - add a new VIRTIO_BLK_F_WCACHE feature. If this feature is set we > do > (a) implement the prepare_flush queue operation to send a > standalone cache flush > (b) set a proper barrier ordering flag on the queue OK, I buy that. I'll update the virtio_pci spec accordingly, too. I've applied your previous patch. > The complex (not to say over engineered) verison would be to split > the caching and data integrity setting into two options: > > (1) hostcache=on|off > use buffered vs O_DIRECT I/O > (2) integrity=osync|fsync|none > use O_SYNC, use f(data)sync or do not care about data integrity If we were starting from scratch, I'd agree. But seems like too much user-visible churn. Thanks, Rusty. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mgqp0-0003hl-TP for qemu-devel@nongnu.org; Thu, 27 Aug 2009 22:04:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mgqow-0003hY-Cx for qemu-devel@nongnu.org; Thu, 27 Aug 2009 22:04:10 -0400 Received: from [199.232.76.173] (port=45240 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mgqow-0003hV-7w for qemu-devel@nongnu.org; Thu, 27 Aug 2009 22:04:06 -0400 Received: from ozlabs.org ([203.10.76.45]:41808) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mgqov-0002uu-Kx for qemu-devel@nongnu.org; Thu, 27 Aug 2009 22:04:05 -0400 From: Rusty Russell Date: Fri, 28 Aug 2009 11:33:59 +0930 References: <20090825181120.GA4863@lst.de> <200908272021.56219.rusty@rustcorp.com.au> <20090827134239.GA13479@lst.de> In-Reply-To: <20090827134239.GA13479@lst.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908281133.59982.rusty@rustcorp.com.au> Subject: [Qemu-devel] Re: Notes on block I/O data integrity List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On Thu, 27 Aug 2009 11:12:39 pm Christoph Hellwig wrote: > On Thu, Aug 27, 2009 at 08:21:55PM +0930, Rusty Russell wrote: > > > - virtio-blk needs to advertise ordered queue by default. > > > This makes cache=writethrough safe on virtio. > > > > >From a guest POV, that's "we don't know, let's say we're ordered because that > > may make us safer". Of course, it may not help: how much does it cost to > > drain the queue? > > > > The bug, IMHO is that we *should* know. And in future I'd like to fix that, > > either by adding an VIRTIO_BLK_F_ORDERED feature, or a VIRTIO_BLK_F_UNORDERED > > feature. > > > > > Action plan for QEMU: > > > > > > - IDE needs to set the write cache enabled bit > > > - virtio needs to implement a cache flush command and advertise it > > > (also needs a small change to the host driver) > > > > So, virtio-blk needs to be enhanced for this as well. > > Really, enabling volatile write caches without advertising a cache flush > command is a bug in the storage, where in our case qemu is the storage. > So I don't really see the need for two feature bits. Here's my plan for > virtio-blk: > > - add a new VIRTIO_BLK_F_WCACHE feature. If this feature is set we > do > (a) implement the prepare_flush queue operation to send a > standalone cache flush > (b) set a proper barrier ordering flag on the queue OK, I buy that. I'll update the virtio_pci spec accordingly, too. I've applied your previous patch. > The complex (not to say over engineered) verison would be to split > the caching and data integrity setting into two options: > > (1) hostcache=on|off > use buffered vs O_DIRECT I/O > (2) integrity=osync|fsync|none > use O_SYNC, use f(data)sync or do not care about data integrity If we were starting from scratch, I'd agree. But seems like too much user-visible churn. Thanks, Rusty.