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

[Kevin Wolf]

Am 19.03.2019 um 17:19 hat Alberto Garcia geschrieben:
> On Mon 18 Mar 2019 04:25:10 PM CET, Vladimir Sementsov-Ogievskiy 
> <address@hidden> 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

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.

> 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.

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.

Now if we assume that the C to A job completes first, we still wouldn't
change the link F -> C, it would still point to C. But what would happen
is indeed wrong:

         F
         |
    A ---+-> C -> D -> E

I don't see why frozen backing file links should prevent this, but it's
still wrong.

You would get the correct result if your second job is from F to A. If
the second job finishes first, this works trivially. However, if the
first job finished first and wants to remove F and therefore change the
parent links from F to C, the frozen link B -> F of the second job
would be a problem.

So it seems frozen links allow the wrong case, but block the correct
one? :-(

> 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.

Maybe at least this kind of freezing isn't the right tool for block
jobs, after all.

Kevin