Re: [Qemu-devel] [v3 03/12] block: Add overlay BDS pointer into the BlockDriverState struct

[Jeff Cody]

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 <address@hidden>
> > ---
> >  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 <address@hidden>
>

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).