From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBScH-0006Qc-LP for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:43:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBSc6-0004Ov-Ux for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:43:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBSc6-0004Og-KN for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:42:58 -0400 Message-ID: <504F5BAC.3040108@redhat.com> Date: Tue, 11 Sep 2012 17:41:32 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <504F514E.40906@redhat.com> <504F5557.4090808@redhat.com> <504F5A70.60300@redhat.com> In-Reply-To: <504F5A70.60300@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/7] block: Framework for reopening files safely List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jcody@redhat.com Cc: supriyak@linux.vnet.ibm.com, pbonzini@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@gmail.com Am 11.09.2012 17:36, schrieb Jeff Cody: > On 09/11/2012 11:14 AM, Kevin Wolf wrote: >> Am 11.09.2012 16:57, schrieb Jeff Cody: >>> On 08/30/2012 02:47 PM, Jeff Cody wrote: >>>> This is based heavily on Supriya Kannery's bdrv_reopen() >>>> patch series. >>>> >>>> This provides a transactional method to reopen multiple >>>> images files safely. >>>> >>>> Image files are queue for reopen via bdrv_reopen_queue(), and the >>>> reopen occurs when bdrv_reopen_multiple() is called. Changes are >>>> staged in bdrv_reopen_prepare() and in the equivalent driver level >>>> functions. If any of the staged images fails a prepare, then all >>>> of the images left untouched, and the staged changes for each image >>>> abandoned. >>>> >>> >>> Open question (my assumption is yes): >>> >>> Is it safe to assume that reopen() should always enable BDRV_O_CACHE_WB >>> (without affecting enable_write_cache), so as to not undo what was done >>> by Paolo's commit e1e9b0ac? >> >> I think it makes sense to behave the same as bdrv_open_common(), so I >> guess yes. But now I'm wondering if we also need other code from there, >> like filtering out BDRV_O_SNAPSHOT/NO_BACKING etc. >> > > I was wondering the same thing w/regards to BDRV_O_SNAPSHOT/NO_BACKING, > but I fell on the side of 'no'. Mainly because the raw drivers (raw-posix, > raw-win32) actively parse the passed flags to determine the actual open > flags, and so spurious flags such as those are ignored. However, > BDRV_O_CACHE_WB is used in their flag parsing logic, so I think it needs > to be preserved. That's probably logic that should be removed in raw-posix/win32.c as it is unused now. Kevin