On 04/09/2016 04:50 AM, Alex Bligh wrote: > > On 8 Apr 2016, at 23:05, Eric Blake <ebl...@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 <ebl...@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
signature.asc
Description: OpenPGP digital signature
