Re: [PATCH 1/7] block: prepare block-stream for using COR-filter - Vladimir Sementsov-Ogievskiy

From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>,
	qemu-block@nongnu.org
Cc: kwolf@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org,
	den@openvz.org, mreitz@redhat.com, jsnow@redhat.com,
	dgilbert@redhat.com
Subject: Re: [PATCH 1/7] block: prepare block-stream for using COR-filter
Date: Tue, 21 Apr 2020 15:23:58 +0300	[thread overview]
Message-ID: <52386567-045e-5e8f-8287-ee8a3edfae72@virtuozzo.com> (raw)
In-Reply-To: <1587407806-109784-2-git-send-email-andrey.shinkevich@virtuozzo.com>

20.04.2020 21:36, Andrey Shinkevich wrote:
> This patch is the first one in the series where the COR-filter node
> will be hard-coded for using in the block-stream job. The job may
> be run with a block-commit job in parallel. Set the condition to
> avoid the job conflicts.

I think, just skipping all filters from checking is wrong.

What is the problem, exactly?

As I understand, we just need the following logic:

stream job, being started with top and base parameters should:

1. calculate bottom-node = non-filter-overlay(base), which assumes finding
last non-filter in a chain from top to base, excluding base

2. I think, we should leave top as is, even if it is filter, it's up to user.

3. add stream-filter above top

4. Take any locks (freeze, op-blockers, etc) on the chain from stream-filter to bottom-node (including both ends), so nobody should touch these nodes. Do not lock any other nodes.

Similarly, commit job, being started with top and base parameters should:

1. I think, if base is a filter, we should set base = non-filter-overlay(base).

2. I think, we should leave top as is, even if it is filter, it's up to user. (hmm, so, commit may be used to remove filters ?)

3. Add commit-filter above top

4. Take any locks (freeze, op-blockers, etc) on the chain from commit-filter to base (including both ends), so nobody should touch these nodes. Do not lock any other nodes.

====

If we make it behave as such, is there still a problem?

> 
> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
> ---
>   blockdev.c | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/blockdev.c b/blockdev.c
> index 758e0b5..72d28ce 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -3297,7 +3297,9 @@ void qmp_block_stream(bool has_job_id, const char *job_id, const char *device,
>       }
>   
>       /* Check for op blockers in the whole chain between bs and base */
> -    for (iter = bs; iter && iter != base_bs; iter = bdrv_filtered_bs(iter)) {
> +    for (iter = bdrv_skip_rw_filters(bs);
> +        iter && iter != bdrv_skip_rw_filters(base_bs);
> +        iter = bdrv_backing_chain_next(iter)) {
>           if (bdrv_op_is_blocked(iter, BLOCK_OP_TYPE_STREAM, errp)) {
>               goto out;
>           }
> @@ -3455,7 +3457,8 @@ void qmp_block_commit(bool has_job_id, const char *job_id, const char *device,
>   
>       assert(bdrv_get_aio_context(base_bs) == aio_context);
>   
> -    for (iter = top_bs; iter != bdrv_filtered_bs(base_bs);
> +    for (iter = bdrv_skip_rw_filters(top_bs);
> +         iter != bdrv_filtered_bs(base_bs);
>            iter = bdrv_filtered_bs(iter))
>       {
>           if (bdrv_op_is_blocked(iter, BLOCK_OP_TYPE_COMMIT_TARGET, errp)) {
> 

-- 
Best regards,
Vladimir