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? > > https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg03224.html > > > > > 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 > responsive).
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 devices yet. 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? Stefan
signature.asc
Description: PGP signature