On 19.08.20 18:50, Kevin Wolf wrote: > Am 25.06.2020 um 17:22 hat Max Reitz geschrieben: >> This includes some permission limiting (for example, we only need to >> take the RESIZE permission for active commits where the base is smaller >> than the top). >> >> Use this opportunity to rename qmp_drive_mirror()'s "source" BDS to >> "target_backing_bs", because that is what it really refers to. >> >> Signed-off-by: Max Reitz <[email protected]> > >> @@ -1682,6 +1721,7 @@ static BlockJob *mirror_start_job( >> s->zero_target = zero_target; >> s->copy_mode = copy_mode; >> s->base = base; >> + s->base_overlay = bdrv_find_overlay(bs, base); >> s->granularity = granularity; >> s->buf_size = ROUND_UP(buf_size, granularity); >> s->unmap = unmap; > > Is this valid without freezing the links between base_overlay and base?
Er... > Actually, I guess we should freeze everything between bs and base (for > base != NULL) and it's a preexisting problem that just happens to affect > this code, too. Yes, that’s how it looks to me, too. I don’t think that has anything to do with this patch. > Or maybe freezing everything is too much. We only want to make sure that > no non-filter is inserted between base and base_overlay and that base > (and now base_overlay) always stay in the backing chain of bs. But what > options apart from freezing do we have to achieve this? I don’t know of any, and I don’t know whether anyone would actually care if we were to just freeze everything. > Why is using base_overlay even better than using base? Assuming there is > a good reason, maybe the commit message could spell it out. The problem is that querying the block status for a filter node falls through to the underlying data-carrying node. So if there’s a filter on top of @base, and we query for is_allocated_above above @base, then we’ll include @base, which we do not want. Max
signature.asc
Description: OpenPGP digital signature
