From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIFfr-0005vH-Cr for qemu-devel@nongnu.org; Mon, 24 Oct 2011 04:14:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIFfq-0003xW-3R for qemu-devel@nongnu.org; Mon, 24 Oct 2011 04:14:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58371) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIFfp-0003xP-Lt for qemu-devel@nongnu.org; Mon, 24 Oct 2011 04:14:21 -0400 Message-ID: <4EA51F16.3030700@redhat.com> Date: Mon, 24 Oct 2011 10:17:26 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1319216912-26964-1-git-send-email-kwolf@redhat.com> <4EA1BD95.8030205@redhat.com> <4EA515B9.8070204@redhat.com> <4EA51963.5060904@redhat.com> In-Reply-To: <4EA51963.5060904@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Alexander Graf , qemu-devel@nongnu.org, avi@redhat.com Am 24.10.2011 09:53, schrieb Paolo Bonzini: > On 10/24/2011 09:37 AM, Kevin Wolf wrote: >>> Why? cache=unsafe is explicitly allowing to s/data/manure/ on >>> crash. >> >> It's surely expected on a host crash, but is it for a qemu crash? >> cache=unsafe was introduced to avoid fsync() costs, which it still >> does after this patch. > > I think it's not about "why is it there", but rather about "what is it > useful for". My interpretation of it is "I do not need the image > anymore unless the command exits cleanly": VM installations, qemu-img > conversions, BDRV_O_SNAPSHOT (doesn't do it yet, but it could). Even > SIGINT and SIGTERM would be excluded from this definition, but they cost > nothing so it's nice to include them. I think another common interpretation is: "I don't run this VM in production but for development. I want the VM to go faster and I can recreate the image in the unlikely event that power fails during my work. But it certainly would be nasty." >>> If you do this for raw-posix, you need to do it for all protocols. >> >> rbd could use it, too, right. Any other protocol I missed? > > NBD could, but it doesn't support flush yet. > > In general, even if it were useful to implement this, I'm not sure this > is the best way to implement it. For example you could simply clear > BDRV_O_NO_FLUSH in qcow2_open. That could work, too. On the other hand I don't like block drivers to modify their flags. For example, would query-block still provide the correct cache mode then? But I think that starting to make exceptions for single block drivers isn't a good idea anyway. If we want bdrv_flush() to write out all metadata internal to qemu, I think the approach with checking the flag in drivers calling things like fsync() is better. The common thing is to do the flush. Kevin