From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53267 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P90sp-0001bP-DW for Qemu-devel@nongnu.org; Thu, 21 Oct 2010 15:33:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P90sk-0000I0-KP for Qemu-devel@nongnu.org; Thu, 21 Oct 2010 15:33:03 -0400 Received: from moutng.kundenserver.de ([212.227.17.9]:62468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P90sk-0000Fg-91 for Qemu-devel@nongnu.org; Thu, 21 Oct 2010 15:32:58 -0400 Subject: Re: [Qemu-devel] bdrv_flush for qemu block drivers nbd, rbd and sheepdog From: Laurent Vivier In-Reply-To: <4CC05744.1060204@codemonkey.ws> References: <4CC04920.8040902@redhat.com> <4CC05744.1060204@codemonkey.ws> Content-Type: text/plain; charset="UTF-8" Date: Thu, 21 Oct 2010 21:32:52 +0200 Message-ID: <1287689572.2724.0.camel@Quad> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Qemu-devel@nongnu.org Le jeudi 21 octobre 2010 =C3=A0 10:07 -0500, Anthony Liguori a =C3=A9crit : > On 10/21/2010 09:07 AM, Kevin Wolf wrote: > > Hi all, > > > > I'm currently looking into adding a return value to qemu's bdrv_flush > > function and I noticed that your block drivers (nbd, rbd and sheepdog) > > don't implement bdrv_flush at all. bdrv_flush is going to return > > -ENOTSUP for any block driver not implementing this, effectively > > breaking these three drivers for anything but cache=3Dunsafe. > > > > Is there a specific reason why your drivers don't implement this? >=20 > NBD doesn't have a notion of flush. Only read/write and the block-nbd= =20 > implementation doesn't do write-caching so flush would be a nop. >=20 > I'm not sure what the right semantics would be for QEMU. My guess is a= =20 > nop flush. I agree. Regards, Laurent > Regards, >=20 > Anthony Liguori >=20 > > I > > think I remember that one of the drivers always provides > > cache=3Dwritethough semantics. It would be okay to silently "upgrade" t= o > > cache=3Dwritethrough, so in this case I'd just need to add an empty > > bdrv_flush implementation. > > > > Otherwise, we really cannot allow any option except cache=3Dunsafe beca= use > > that's the semantics provided by the driver. > > > > In any case, I think it would be a good idea to implement a real > > bdrv_flush function to allow the write-back cache modes cache=3Doff and > > cache=3Dwriteback in order to improve performance over writethrough. > > > > Is this possible with your protocols, or can the protocol be changed to > > consider this? Any hints on how to proceed? > > > > Kevin > > > > =20 >=20 --=20 --------------------- laurent@vivier.eu ---------------------- "Tout ce qui est impossible reste =C3=A0 accomplir" Jules Verne "Things are only impossible until they're not" Jean-Luc Picard