[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] NBD handshake may block qemu main thread w
Re: [Qemu-devel] [Qemu-block] NBD handshake may block qemu main thread when socket delays or has packet loss
Thu, 12 Jan 2017 14:40:06 +0000
On Wed, Jan 04, 2017 at 02:44:53PM -0600, Eric Blake wrote:
> On 01/04/2017 02:45 AM, Fangyi (C) wrote:
> > As we all know, socket is in blocking mode when nbd is negotiating
> > with the other end. If the network is poor because of delay or packet
> > loss, socket read or write will return very slowly. The mainloop events
> > won't be handled in time util nbd handshake ends.
> I wonder if Paolo's work to improve NBD coroutine usage after handshakes
> can be leveraged here?
> > Any advices to solve the problem?
> At any rate, it sounds like someone will have to patch NBD code to use
> coroutines instead of blocking for the handshake portion (and that's
> true in general - ANY operation that can block should probably be
> refactored into aio or coroutines so that the main loop can remain
This is a general issue with network block drivers. They tend to do
blocking DNS resolution, blocking connection, and blocking protocol
handshake/negotiation in .bdrv_open().
We cannot expose a block device to the guest before it has been opened
because the disk's capacity is unknown plus the guest would experience
I/O timeouts or errors.
I think we need to agree on how to handle this for all different types
of network protocols, not just nbd, before code can be written.
One starting point is:
Should we make .drv_open() a coroutine and introduce a async concept to
blockdev_add, reopen, etc?
The BlockDriverState would be in a special OPENING or OFFLINE state
where its name is reserved but it cannot be used for I/O or emulated
QMP clients would have watch out for an event that tells them that it's
now okay to device-add the emulated storage device using the drive.
Any ideas for a nicer solution?
Description: PGP signature