From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIGCB-0001qz-4F for qemu-devel@nongnu.org; Mon, 24 Oct 2011 04:47:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIGC9-00012d-Rb for qemu-devel@nongnu.org; Mon, 24 Oct 2011 04:47:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIGC9-00012U-Ia for qemu-devel@nongnu.org; Mon, 24 Oct 2011 04:47:45 -0400 Message-ID: <4EA5262D.7090901@redhat.com> Date: Mon, 24 Oct 2011 10:47:41 +0200 From: Paolo Bonzini 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> <4EA51F16.3030700@redhat.com> In-Reply-To: <4EA51F16.3030700@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Kevin Wolf Cc: Alexander Graf , qemu-devel@nongnu.org, avi@redhat.com On 10/24/2011 10:17 AM, Kevin Wolf wrote: > > 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." Fair enough. > 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. I don't know... checking BDRV_O_NO_FLUSH in the drivers rather than in the generic code sounds like a layering violation. Perhaps what you're after is a separation of bdrv_co_flush from bdrv_{,co_,aio_}fsync? Then BDRV_O_NO_FLUSH (better renamed to BDRV_O_NO_FSYNC...) would only inhibit the latter. Paolo