From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZEEt-0002E3-0t for qemu-devel@nongnu.org; Fri, 26 Feb 2016 03:59:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZEEs-0007b8-0s for qemu-devel@nongnu.org; Fri, 26 Feb 2016 03:59:06 -0500 Date: Fri, 26 Feb 2016 09:58:54 +0100 From: Kevin Wolf Message-ID: <20160226085854.GA5668@noname.redhat.com> References: <87083486787f4d4b9752f4b29209e6d0d1d31626.1455033112.git.berto@igalia.com> <56CDD70F.8000304@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2 1/2] block: Allow x-blockdev-del on a BB with a monitor-owned BDS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz Am 25.02.2016 um 12:11 hat Alberto Garcia geschrieben: > On Wed 24 Feb 2016 05:15:11 PM CET, Max Reitz wrote: > > >> When x-blockdev-del is performed on a BlockBackend that has inserted > >> media it will only succeed if the BDS doesn't have any additional > >> references. > >> > >> The only problem with this is that if the BDS was created separately > >> using blockdev-add then the backend won't be able to be destroyed > >> unless the BDS is ejected first. This is an unnecessary restriction. > > > > Is it? In order to get into this situation, you need to execute: > > blockdev-add (BB/BDS), blockdev-add (BDS/BB), x-blockdev-insert-medium > > > > Now, in order to unravel it, you currently need: > > x-blockdev-remove-medium (or eject), x-blockdev-del (BB/BDS), > > x-blockdev-del (BDS/BB) > > > > So you need to execute the x-blockdev-remove-medium because you did an > > x-blockdev-insert-medium before. That seems reasonable to me, and not > > very superfluous. > > I think your case is reasonable, but it's not the only way to get into > this situation. See for example this one: > > blockdev-add 'drive0', 'node0' > blockdev-add 'node1' > blockdev-snapshot node='node0' overlay='node1' > > Now you have 'drive0' with 'node0' <- 'node1'. > > You cannot simply remove 'drive0', you need to eject 'node1' first and > then you can remove 'drive0' and 'node1'. I think this is even more a reason not to introduce any magic but to require that node and BB be removed separately. Otherwise it will become really confusing to track for management software which node is supposed to automatically go away and which isn't. That said, I'm still hoping to somehow find a compatible way to completely hide BBs so that they are automatically created and deleted whenever a new user attaches to a BDS. Kevin