From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIHB5-0000RD-FY for qemu-devel@nongnu.org; Mon, 24 Oct 2011 05:50:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIHB4-00042j-1u for qemu-devel@nongnu.org; Mon, 24 Oct 2011 05:50:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIHB3-00042a-R8 for qemu-devel@nongnu.org; Mon, 24 Oct 2011 05:50:42 -0400 Message-ID: <4EA535AB.3010805@redhat.com> Date: Mon, 24 Oct 2011 11:53:47 +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> <4EA51F16.3030700@redhat.com> <4EA5262D.7090901@redhat.com> <4EA527DC.90902@redhat.com> <4EA52F2E.4000302@redhat.com> <4EA53184.8080201@redhat.com> <4EA5329C.3000003@redhat.com> In-Reply-To: <4EA5329C.3000003@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: avi@redhat.com, Alexander Graf , qemu-devel@nongnu.org Am 24.10.2011 11:40, schrieb Paolo Bonzini: > On 10/24/2011 11:36 AM, Kevin Wolf wrote: >>>> You're changing the API and asking for possibly non-trivial changes in >>>> all protocol drivers, in order to accomodate semantics that all format >>>> drivers potentially could desire. So I wonder if the problem is simply >>>> that the current API is not expressive enough. >> Can you think of any cases where a caller would want to invoke >> bdrv_flush, but not bdrv_fsync? (The other way round it makes even less >> sense) > > I'm talking about the internal driver API only. The external API is > fine as is. Ok, so external callers don't force us to do it. Yes, we could split bdrv_flush internally into two functions for "flush one level to the OS" and "flush all the way down to the disk", but I'm not sure if this really buys us anything or just adds complexity. Kevin