Re: [Qemu-devel] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node

[Vladimir Sementsov-Ogievskiy]

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,
Vladimir