On Mon 18 Mar 2019 04:25:10 PM CET, Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> wrote: >> 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".
Oh, I see. Let's use a shorter chain for simplicity: A <- B <- C <- D <- E 1) If we stream first from E to C we add a filter F: A <- B <- F <- C <- D <- E Now we can't stream from C to A because F is on the way, and the F-C link is frozen. 2) If we stream first from C to A the filter goes on top of A: F <- A <- B <- C <- D <- E But now we can't stream from E to C, because that would insert a filter between B and C and that link is frozen. I think it's unfortunate that implemeting block-stream with a filter restricts this kind of scenarios, but I don't see a simple solution, and I don't think this use case justifies making the code more complicated. Berto
