qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrey Shinkevich
Subject: Re: [Qemu-block] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node
Date: Thu, 21 Mar 2019 17:11:58 +0000


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]