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

[Kevin Wolf]

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