On 27.11.2016 02:56, Max Reitz wrote: > If the backing file is overridden, this most probably does change the > guest-visible data of a BDS. Therefore, we will need to consider this in > bdrv_refresh_filename(). > > Adding a new field to the BDS is not nice, but it is very simple and > exactly keeps track of whether the backing file has been overridden. > > Signed-off-by: Max Reitz <[email protected]> > --- > While this patch adds a TODO comment that sounds like it could be > resolved in a later patch in this series, it is not. > > Checking whether @options contains significant runtime options is not > trivial, because we not only care about significant options at that > level but also at levels below: Normally, it should be fine to check > that for backing_hd and backing_hd->file->bs, but that's not for sure. > So I decided a false positive is better than a false negative here, > which is why the TODO persists throughout the series.
Of course I only noticed after I had sent this series that this was wrong: It breaks iotest 030, and that is because even just giving a node name to a backing node will now result in the backed file getting a JSON filename. That is very unfortunate if one then tries to address files in the backing chain by filename (which, very unfortunately, we do for block-stream and block-commit). So I guess in v3 I will do what I hinted at above: Shallow-clone the options before @driver is set and after backing_hd has been opened, check whether there are any significant options for either backing_hd or backing_hd->file->bs. Max > --- > block.c | 14 ++++++++++++++ > block/mirror.c | 4 ++++ > blockdev.c | 16 ++++++++++++++++ > include/block/block_int.h | 1 + > 4 files changed, 35 insertions(+)
signature.asc
Description: OpenPGP digital signature
