Re: [Qemu-devel] [PATCH 16/18] nbd: Support NBD_CMD_CLOSE

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On 04/09/2016 04:50 AM, Alex Bligh wrote:
> 
> On 8 Apr 2016, at 23:05, Eric Blake <eblake@redhat.com> wrote:
> 
>> NBD_CMD_DISC is annoying: the server is not required to reply,
>> so the client has no choice but to disconnect once it has sent
>> the message; but depending on timing, the server can see the
>> disconnect prior to reading the request, and treat things as
>> an abrupt exit rather than a clean shutdown (which may affect
>> whether the server properly fsync()s data to disk, and so on).
>> The new NBD_CMD_CLOSE adds another round of handshake, where
>> the client waits for the server's action before closing, to
>> make sure both parties know that it was a clean close rather
>> than an accidental early disconnect.
>>
>> In nbd-client.c, nbd_client_close() is called after we have
>> already exited the normal coroutine context used by all the
>> other transmission phase handlers, so the code is a bit more
>> complex to build up a coroutine just for the purpose of waiting
>> for the server's response.
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
> 
> Wouter is not yet convinced of the merits of NBD_CMD_CLOSE
> so we should probably resist applying this unless / until we
> have convinced him of its benefits.
> 
> BTW there is nothing to stop you doing an fsync() on ANY
> disconnect server side.

Qemu clients _already_ do the safe actions of waiting for all inflight
requests to complete, then sending one final NBD_CMD_FLUSH, before
attempting to send NBD_CMD_DISC.  If I knew how to make qemu guarantee
that the NBD_CMD_DISC hits the wire (even in TLS mode) rather than being
dropped early, that seems nicer than having to implement this (although
I did learn a bit about qemu coroutines in implementing this).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]