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 15:36:23 +0000


On 20/03/2019 20:02, Alberto Garcia wrote:
> 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?).

I manage the issue by removing the filter F after the chain A-C is
unfrozen in the stream_prepare().

> 
>> So it seems frozen links allow the wrong case, but block the correct
>> one? :-(
> 
> Yes, we probably need to rethink this scenario a bit.
> 
> Berto
> 

-- 
With the best regards,
Andrey Shinkevich

reply via email to

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