[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v7 33/47] mirror: Deal with filters
From: |
Kevin Wolf |
Subject: |
Re: [PATCH v7 33/47] mirror: Deal with filters |
Date: |
Wed, 19 Aug 2020 18:50:36 +0200 |
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 <mreitz@redhat.com>
> @@ -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?
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.
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?
Why is using base_overlay even better than using base? Assuming there is
a good reason, maybe the commit message could spell it out.
Kevin
- Re: [PATCH v7 33/47] mirror: Deal with filters,
Kevin Wolf <=