On 21/03/2019 14:53, Vladimir Sementsov-Ogievskiy wrote: > 21.03.2019 13:53, Kevin Wolf wrote: >> Am 20.03.2019 um 18:02 hat Alberto Garcia geschrieben: >>> On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote: >>>>> Oh, I see. Let's use a shorter chain for simplicity: >>>>> >>>>> A <- B <- C <- D <- E >>>> >>>> Written from right to left, i.e. E being the base and A the top layer? >>>> We usually write things the other write round, I hope this doesn't get >>>> too confusing later. >>> >>> Oh my... yes, of course you're right, I should have written it the other >>> way around: >>> >>> E <- D <- C <- B <- A >>> >>>>> 1) If we stream first from E to C we add a filter F: >>>>> >>>>> A <- B <- F <- C <- D <- E >>> >>> ( which should have been written E <- D <- C <- F <- B <- A ) >>> >>>>> Now we can't stream from C to A because F is on the way, and the F-C >>>>> link is frozen. >>>> >>>> Why is a frozen link a problem? The streaming operation isn't going to >>>> change this link, it just copies data from the subchain (including F >>>> and C) to A. This is not something that a frozen link should prevent. >>> >>> Not the operation itself, but the first thing that block-stream does is >>> freeze the chain from top (A) to base (C), so this would fail if there's >>> already a frozen link on the way (C <- F on this case?). >> >> Oh, I see. I think this is why I suggested a counter originally instead >> of a bool. >> >>>> So it seems frozen links allow the wrong case, but block the correct >>>> one? :-( >>> >>> Yes, we probably need to rethink this scenario a bit. >> >> But yes, even with a counter, the other problem would still remain (that >> the first job can't remove the filter on completion because the second >> one has frozen its link to the filter). >> >> I don't think that's a case we want to just forbid because nobody needs >> this anyway. It's a sign of a more fundamental problem in our design, >> and I'm sure it will bite us in other places, too. >> >> Kevin >> > > Does it mean that we now have problems with other jobs which already has > filter if use them in parallel with stream? >
In the current implementation of the iotests, only the TestParallelOps::test_stream_parallel() in the #030 detects the issue. Andrey
