From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIGtw-0002wq-B4 for qemu-devel@nongnu.org; Mon, 24 Oct 2011 05:33:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIGtv-0000o0-CP for qemu-devel@nongnu.org; Mon, 24 Oct 2011 05:33:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62679) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIGtv-0000nw-1j for qemu-devel@nongnu.org; Mon, 24 Oct 2011 05:32:59 -0400 Message-ID: <4EA53184.8080201@redhat.com> Date: Mon, 24 Oct 2011 11:36:04 +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> In-Reply-To: <4EA52F2E.4000302@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:26, schrieb Paolo Bonzini: > On 10/24/2011 10:54 AM, Kevin Wolf wrote: >>> 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. >> >> Why? All other cache related BDRV_O_* flags are interpreted by the block >> drivers, so why should BDRV_O_NO_FLUSH be special? > > 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) Kevin