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

[Vladimir Sementsov-Ogievskiy]

20.03.2019 12:16, Kevin Wolf wrote:
> 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.

I think it should be enough to not share WRITE_PERM by F-C link, to restrict
this.

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

I think, the correct way, which will support these correct cases (which however
don't look like real use cases) is removing base from stream view. Stream
should operate instead using bottom-node. And changing backing link of this
bottom-node to some new base (filter for ex.) will be transparent for stream.

But for this we should change interface (as it uses base), or at least 
recalculate
base to bottom-node as a first action of the job, before any yield.

Also, we'll need block_status operation to support bottom_node instead of base.

And this all looks really more complicated than what we already have with frozen
backing chain.

Do we really need such cases with parallel streams, sharing same node as base 
for
one and top for another? Will someone be upset if we drop usage for such 
scenarios?

-- 
Best regards,
Vladimir