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
