qemu-block
[Top][All Lists]
Advanced

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

DROP THIS Re: [PATCH 00/14] nbd: move reconnect-thread to separate file


From: Vladimir Sementsov-Ogievskiy
Subject: DROP THIS Re: [PATCH 00/14] nbd: move reconnect-thread to separate file
Date: Thu, 8 Apr 2021 13:03:55 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0

07.04.2021 13:46, Vladimir Sementsov-Ogievskiy wrote:
Hi all!

There are problems with nbd driver:

  - nbd reconnect is cancelled on drain, which is bad as Roman describes
    in his "[PATCH 0/7] block/nbd: decouple reconnect from drain"
  - nbd driver is too complicated around drained sections and aio context
    switch. It's nearly impossible to follow all the logic, including
    abuse of bs->in_flight, which is temporary decreased in some places
    (like nbd_read_eof()). Additional reconnect thread and two different
    state machines (we have BDRVNBDState::state and
    BDRVNBDState::connect_thread->state) doesn't make things simpler :)

So, I have a plan:

1. Move nbd negotiation to connect_thread

2. Do receive NBD replies in request coroutines, not in connection_co
At this point we can drop connection_co, and when we don't have
    endless running coroutine, NBD driver becomes a usual block driver,
    and we can drop abuse of bs->in_flight, and probably drop most of
    complicated logic around drained section and aio context switch in
    nbd driver.

3. Still, as Roman describes, with [2] we loose a possibility to
    reconnect immediately when connection breaks (with current code we
    have endless read in reconnect_co, but actually for this to work
    keep-alive should be setup correctly). So, we'll need to reinvent it,
    checking connection periodically by timeout, with help of getsockopt
    or just sending a kind of PING request (zero-length READ or something
    like this).

And this series a kind of preparation. The main point of it is moving
connect-thread to a separate file.



Finally I don't like it. I'm in progress of creating new series to substitute 
this one, so don't waste your time on review.


--
Best regards,
Vladimir



reply via email to

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