On 04/13/2016 04:25 AM, Alex Bligh wrote: > Wouter, > >>> +A client MAY use a soft disconnect to terminate the session >>> +whenever it wishes, provided that there are no outstanding >>> +replies to options. >> >> NAK. A client MAY use a soft disconnect *at any time*, but the server >> MUST NOT act upon it until there are no outstanding replies, and the >> client MUST NOT send any further options after sending NBD_OPT_ABORT. >> >> (same for CMD_DISC) > > This gets to the root of the unresolved issues I think. I suspect > the answer may be different for NBD_OPT_ABORT and NBD_CMD_DISC. > > NBD commands are asynchronous and can be replied and acted on > in any order (so, from the document): > > "The server MAY process commands out of order, and MAY reply > out of order" > > I wouldn't want to loose that. So if the client sends NBD_CMD_DISC > without waiting for all his inflight commands to complete, those > inflight commands may not be executed at all, because the server > is free to process commands in any order. It's going to make > server design very awkward if you can only process /some/ commands > out of order.
We already have that constraint - commands with NBD_CMD_FLAG_FUA must be processed in a particular order, and NBD_CMD_FLUSH must be processed in a particular order. Requiring NBD_CMD_DISC to be processed last is not much different than these other two situations (well, different in that the other two only have to guarantee that commands _with replies_ have hit permanent storage, not ALL commands received). > Another alternative would be to make the server > wait for all commands to complete before acting on the disconnect > (as opposed to or in addition to making the client wait to send > it). I'm reasonably relaxed about which one we do, but I think > we should do one or the other (or at least say that if the > client sends NBD_CMD_DISC without waiting for commands to complete > then those commands must not be executed). There are thus > various choices for NBD_CMD_DISC. I think it is perfectly fair to put the requirement on the server that it MUST wait until all inflight commands have been responded to before disconnecting; and at the same time that a client SHOULD wait until there are no inflight commands before sending NBD_CMD_DISC. > > I think the option haggling phase is different (or rather need > not be the same). Fundamentally options MUST be processed in > the order they are issued, No, we already explicitly state that options may be replied to out-of-order, and that the burden is on the client to wait for particular replies before sending another option of the same type. > and there is only ever one in > flight at a time. No, a client can batch send a bunch of options before waiting for any replies. >> >> It might be good to add a "NBD_REP_ERR_NOSERVICE" error, for "server >> shutting down"? > > I think that's probably a good idea. That only works during handshake phase; you may also want to add a specific error value for use during transmission phase (maybe ECONNRESET? ENOLINK? EPIPE? ESHUTDOWN?) -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
