From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uoqh2-0000eb-8D for qemu-devel@nongnu.org; Tue, 18 Jun 2013 03:51:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uoqh0-0002jl-PZ for qemu-devel@nongnu.org; Tue, 18 Jun 2013 03:51:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uoqh0-0002ij-Hm for qemu-devel@nongnu.org; Tue, 18 Jun 2013 03:51:06 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5I7p58Y008735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Jun 2013 03:51:05 -0400 Date: Tue, 18 Jun 2013 09:51:03 +0200 From: Kevin Wolf Message-ID: <20130618075102.GC3640@dhcp-200-207.str.redhat.com> References: <20130617093241.GA22609@localhost.nay.redhat.com> <51BEDCB9.5090905@redhat.com> <20130617135253.GB3994@dhcp-200-207.str.redhat.com> <51BF16B8.6040801@redhat.com> <20130617142605.GD3994@dhcp-200-207.str.redhat.com> <51BF213F.60601@redhat.com> <20130617151238.GF3994@dhcp-200-207.str.redhat.com> <20130618035854.GA17533@localhost.nay.redhat.com> <20130618063256.GB3640@dhcp-200-207.str.redhat.com> <20130618070023.GA1220@localhost.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130618070023.GA1220@localhost.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH] block: add 'backing' option to drive_add List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org, stefanha@redhat.com, Eric Blake , armbru@redhat.com Am 18.06.2013 um 09:00 hat Fam Zheng geschrieben: > On Tue, 06/18 08:32, Kevin Wolf wrote: > > Am 18.06.2013 um 05:58 hat Fam Zheng geschrieben: > > > On Mon, 06/17 17:12, Kevin Wolf wrote: > > > > Am 17.06.2013 um 16:46 hat Paolo Bonzini geschrieben: > > > > > Il 17/06/2013 16:26, Kevin Wolf ha scritto: > > > > > > Am 17.06.2013 um 16:01 hat Paolo Bonzini geschrieben: > > > > > >> Il 17/06/2013 15:52, Kevin Wolf ha scritto: > > > > > >>> It's not a new thought that we need to change the block layer so that a > > > > > >>> BlockDriverState can't be "empty", but that one BlockDriverState always > > > > > >>> refers to one image. If you change media, you attach a different > > > > > >>> BlockDriverState to the device. Once you have this, you can start > > > > > >>> refcounting BlockDriverStates, so that the backing file remains usable > > > > > >>> while the guest device already uses a different image. > > > > > >>> > > > > > >>> Not that it's it easy to get there... > > > > > >> > > > > > >> I'm not sure that is safe to do. > > > > > >> > > > > > >> Consider the case where the guest switches from A to B during backup, > > > > > >> and then from B to A. You get two BDS for the same file, which pretty > > > > > >> much means havoc. > > > > > > > > > > > > Well, yes, it means that the management tool needs to know what it's > > > > > > doing. It shouldn't create a second BDS for A, but reattach the still > > > > > > existing one. > > > > > > > > > > How? That would require the management tool to know the full chain of > > > > > BDSes that were opened in the past. > > > > > > > > They better know on which files they are operating. It's not like the > > > > management could be unaware of running backup jobs or things like that. > > > > > > > > > > Is there any case that QEMU needs to have two BDS pointing to the same > > > file? > > > > No, I think there's no case where this would make sense. > > > > > If not, can we try to detect such case on opening and try to > > > reuse the bs? > > > > We can't do it reliably, think about symlinks or even hard links, or > > things like /dev/fdset/..., let alone remote protocols that refer to the > > same image file etc. > > > > We can check the obvious cases and error out for them, but that's about > > what we can do. I don't think we should try to fix things automagically > > when we can't do it right. > > It's impossible to know a remote protocol points to the same image with > local file path, that's not in QEMU's scope, but we have a good chance > to detect (strcmp with existing bs->filename) and error out Paolo's > A-B-A problem, don't we? Yes, catching 50% of the misuses is better than catching none. My point was that we shouldn't "try to reuse the bs" when we detect that the file is already open, because that makes it a feature that users are supposed to use and that doesn't work consistently across backends and will therefore cause endless pain. If we detect it (in order to protect the user from his own mistakes), we must treat it as a misuse and return an error. Kevin