[Top][All Lists]

[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: Alberto Garcia
Subject: Re: [Qemu-block] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node
Date: Tue, 19 Mar 2019 17:19:05 +0100
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

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

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.

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.


reply via email to

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