[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH 1/2] iotests: 030 TestParallelOps non-shared bas

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node
Date: Mon, 18 Mar 2019 15:25:10 +0000

18.03.2019 18:05, Alberto Garcia wrote:
> On Thu 21 Feb 2019 04:26:38 PM CET, Andrey Shinkevich wrote:
>> The test case TestParallelOps::test_stream_parallel in #030 fails
>> if a base node is protected by the block-stream running job that
>> includes the base node into the job node list (block_job_add_bdrv)
>> without BLK_PERM_GRAPH_MOD shared permission.
>> The block-stream job would own the base node not allowing it to go
>> away due to the graph modification, e.g. when a filter node is
>> inserted above a top node of the parallel job. That's, the base
>> node was shared between the two parallel jobs.
>> This patch excludes sharing the node by inserting additional nodes
>> inbetween.
> So what we have now is:
>     A <- B <- C <- D <- E <- F <- G <- H <- I
> and we can launch four parallel block-stream jobs:
>     From C (base) to A
>     From E (base) to C
>     From G (base) to E
>     From I (base) to G
> These jobs share nodes (the base node of each one is the active node of
> the next), but that's ok. From the base node we only require that the
> guest-visible data does not change.

But with filters you cant.

assume that "From E (base) to C" is already running. It means, that there
is a filter inserted between B and C. Then you want to start
"From C (base) to A". But it's illegal, because this range includes filter,
which belong to "From E (base) to C". "From E (base) to C"

And even if you instead select somehow this filter to be the base for
"From C (base) to A", so jobs are not intersecting, it's wrong, as if
"From E (base) to C" finish earlier, it will want to remove its filter,
which will fail, as backing link form B to it is frozen.

> If I understand it correctly your patch blocks the base node for the
> stream job, so it's not possible to share it anymore like we are doing
> now and you need to insert additional nodes.
> This seems unnecessary. I wrote this test to check precisely that very
> scenario. It works and I don't see any reason why it shouldn't. As I
> said in the e-mail that I sent some minutes ago, if what we want is to
> prevent the base node from disappearing it seems that we have better
> tools for that now.
> Berto

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]