On Fri, May 30, 2014 at 10:00:09AM -0600, Eric Blake wrote: > On 05/30/2014 09:35 AM, Jeff Cody wrote: > > Now that node-names can reference an individual BlockDriverState without > > needing to navigate downwards from the 'device' level, in order to find > > the top-most image (active layer) we need a pointer to the overlay of a > > BDS. > > > > This will allow QMP commands to reference an image solely by its > > node-name, without also needing to pass in the corresponding 'device' > > string. > > > > This also adds a helper function to set the overlay pointer that is, for > > now, trivial. But since we recently moved away from open coding > > bs->backing_hd assignment, we should probably also refrain from setting > > bs->overlay directly. > > > > Signed-off-by: Jeff Cody <jc...@redhat.com> > > --- > > block.c | 14 ++++++++++++++ > > include/block/block.h | 1 + > > include/block/block_int.h | 1 + > > 3 files changed, 16 insertions(+) > > Question - can one bds ever belong to more than one chain? That is, > could I create a guest that uses: > / disk1 > base < > \ disk2 > > for two disks in parallel, but where I use blockdev referencing to pass > in a single readonly copy of base to both chains rather than the default > of opening base twice? If so, then what does the overlay field get set > to for base: disk1 or disk2? On the other hand, if base truly is > shared, it's non-deterministic which device is meant when using just the > node-name for the shared base bds. So maybe the user gets what they > deserved. Or maybe it argues that doing a bds lookup for a bds that has > more than one device chain returns a failure unless the device chain was > passed as well (but that may mean reference counting or even tracking an > array of overlays). > > But if a bds can be in at most one chain at a time, then your patch > makes sense. > > Reviewed-by: Eric Blake <ebl...@redhat.com> >
While an image itself may be a backing file to more than one overlay image, QEMU would open that as 2 separate chains, as we open the drive from the active layer downwards, following the backing_file. So in the QEMU implementation of your above structure, a BDS will be in at most one chain at a time: [0 base] <-- [1 disk1] [2 base] <-- [3 disk2] In the above case, each '[]' is a unique BDS structure. (and of course, if you perform a block-commit to an image that is a base to multiple other images, then expect Bad Things).
