[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 10/12] block.c: add subtree_drains where needed
From: |
Emanuele Giuseppe Esposito |
Subject: |
Re: [PATCH 10/12] block.c: add subtree_drains where needed |
Date: |
Thu, 3 Feb 2022 11:09:14 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 |
On 02/02/2022 18:38, Paolo Bonzini wrote:
> On 2/2/22 16:37, Emanuele Giuseppe Esposito wrote:
>> So we have disk B with backing file C, and new disk A that wants to have
>> backing file C.
>>
>> I think I understand what you mean, so in theory the operation would be
>> - create new child
>> - add child to A->children list
>> - add child to C->parents list
>>
>> So in theory we need to
>> * drain A (without subtree), because it can't happen that child nodes of
>> A have in-flight requests that look at A status (children list),
>> right?
>> In other words, if A has another node X, can a request in X inspect
>> A->children
I am not sure if this can happen. It doesn't seem so, though. All
functions inspecting ->parents are either GS or don't call recursive
function that go down on children list again.
>> * drain C, as parents can inspect C status (like B). Same assumption
>> here, C->children[x]->bs cannot have requests inspecting C->parents
>> list?
What if C->children[x]->bs drains? we would have a child inspecting
C->parents.
>
> In that case (i.e. if parents have to be drained, but children need not)
> bdrv_drained_begin_unlocked would be enough, right?
Should be, if that is the case.
>
> That would mean that ->children is I/O state but ->parents is global
> state. I think it's quite a bit more complicated to analyze and to
> understand.
Not sure I follow this one, why is ->parents GS? it is also used by the
drain API...
Emanuele