From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmQWK-0006af-1F for qemu-devel@nongnu.org; Thu, 28 Jul 2011 09:21:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmQWJ-0003V9-87 for qemu-devel@nongnu.org; Thu, 28 Jul 2011 09:21:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmQWJ-0003Uw-0H for qemu-devel@nongnu.org; Thu, 28 Jul 2011 09:20:59 -0400 Message-ID: <4E3162D8.9080702@redhat.com> Date: Thu, 28 Jul 2011 15:23:36 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <20110727113000.25109.16204.sendpatchset@skannery> <20110727113045.25109.54866.sendpatchset@skannery> <4E3015EC.7070004@msgid.tls.msk.ru> <4E31389A.4080609@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [V5 Patch 3/4]Qemu: Command "block_set" for dynamic block params change List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Supriya Kannery , Michael Tokarev , qemu-devel@nongnu.org, Christoph Hellwig Am 28.07.2011 15:10, schrieb Stefan Hajnoczi: > On Thu, Jul 28, 2011 at 11:23 AM, Kevin Wolf wrote: >> Am 27.07.2011 16:51, schrieb Stefan Hajnoczi: >>> I'll think about this some more, there are a couple of solutions like >>> keeping only the file descriptor around, introducing a flush command >>> that makes sure the file is in a clean state, or changing QED to not >>> do this. >> >> Changing the format drivers doesn't really look like the right solution. >> >> Keeping the fd around looks okay, we can probably achieve this by >> introducing a bdrv_reopen function. It means that we may need to reopen >> the format layer, but it can't really fail. > > My concern is that this assumes a single file descriptor. For vmdk > there may be multiple split files. > > I'm almost starting to think bdrv_reopen() should be recursive down > the BlockDriverState tree. Yes, VMDK would have to call bdrv_reopen() for each file that it uses. Kevin