Re: [RFC Patch v3 13/22] blktap2: connect to backup asynchronously

[Wen Congyang <wency@cn.fujitsu.com>]

On 09/25/2014 03:11 AM, Shriram Rajagopalan wrote:
> On Sep 5, 2014 5:30 AM, "Wen Congyang" <wency@cn.fujitsu.com> wrote:
>>
>> tapdisk2 is a single thread process. If we use remus,
>> we will block in primary_blocking_connect(). The
>> user will not have any chance to talk with tapdisk2.
>> So we should connect to backup asynchronously.
>> Before the connection is established, we queue
>> all I/O request, and handle it when the connection
>> is established.
>>
> 
> Hi
>   This is useful functionality but also very dangerous. I am afraid your
> comments are quite sparse in addressing how the I/O requests are handled at
> the primary until the connection is established.
> Before this patch, the guest would block halfway through boot, until the
> backup connection is established. What happens after this patch?

This patch doesn't change the behavior. ALl I/O requests are queued in a list.
When the connection is established, we will handle the pended request.

> Will the guest's write requests go through? If so, are you merging writes
> to same block in your internal ring? What about reads? Do you query your in
> memory queue to serve these reads?

Before the connections is established, if there are no pended I/O requests,
the read requests can just go through. If there are some pended I/O requests,
read requests are also pended. All write requests are pended before the connection
is established. After the coonection is established, read reqeusts can just go
through, and write requests are forwarded and go through.

>   You are basically introducing a copy on write semantics at the primary
> until a backup connection is established, with the faulting writes and
> subsequent reads being served out of memory. What happens to the network io
> during this wait time? Are all outputs blocked?
> The DRBD version allows the primary to function just like a normal VM until
> Remus is started. When Remus is started, it ensures that both disks are in
> sync before the initial migration starts. Are you doing something similar
> here?

No, block-remus doesn't support it now, and it is hard to implement, because
we don't have meta data, and we don't care the file format.

> 
> The patch is unfortunately too mangled to follow. You may have to break it
> up, as the diff lines seem to straddle across function boundaries in
> confusing ways, making it hard to understand.
> 

OK, I will try it. And I think I need to update the commit log too.

Thanks
Wen Congyang