From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBSVv-0004wx-Ux for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:36:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBSVm-0002KT-Ca for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:36:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBSVm-0002KP-3c for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:36:26 -0400 Message-ID: <504F5A70.60300@redhat.com> Date: Tue, 11 Sep 2012 11:36:16 -0400 From: Jeff Cody MIME-Version: 1.0 References: <504F514E.40906@redhat.com> <504F5557.4090808@redhat.com> In-Reply-To: <504F5557.4090808@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 Reply-To: jcody@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: supriyak@linux.vnet.ibm.com, pbonzini@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@gmail.com 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.