Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

Wouter, >> There are two issues here. >> >> Firstly, I would prefer that there is at least a SHOULD NOT condition >> against sending a disconnect before the client has received replies. >> You don't agree with that, and that's fine, I'm going with your >> view (at least for the purposes of this

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On Thu, Apr 14, 2016 at 12:29:09PM +0100, Alex Bligh wrote: > Wouter, > > On 14 Apr 2016, at 07:49, Wouter Verhelst wrote: > > > On Wed, Apr 13, 2016 at 01:21:17PM +0100, Alex Bligh wrote: > >> Secondly I think you are doing exactly what I said below. You > >> are processing it

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

Wouter, On 14 Apr 2016, at 07:49, Wouter Verhelst wrote: > On Wed, Apr 13, 2016 at 01:21:17PM +0100, Alex Bligh wrote: >> Wouter, >> >> On 13 Apr 2016, at 12:44, Wouter Verhelst wrote: >> >>> Hi Alex, >>> >>> On Wed, Apr 13, 2016 at 11:25:02AM +0100, Alex Bligh

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On Wed, Apr 13, 2016 at 05:09:49PM +0100, Alex Bligh wrote: [...] > On 13 Apr 2016, at 16:39, Eric Blake wrote: > > and at the same time that a client SHOULD wait until > > there are no inflight commands before sending NBD_CMD_DISC. > > I like that. I think Wouter doesn't.

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On Wed, Apr 13, 2016 at 01:21:17PM +0100, Alex Bligh wrote: > Wouter, > > On 13 Apr 2016, at 12:44, Wouter Verhelst wrote: > > > Hi Alex, > > > > On Wed, Apr 13, 2016 at 11:25:02AM +0100, Alex Bligh wrote: > >> Wouter, > >> > +A client MAY use a soft disconnect to terminate

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On 13 Apr 2016, at 17:09, Alex Bligh wrote: > Here's what > https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt > has to say: Aha. I found the original thread where I asked about this (it was on linux-fsdevel):

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On 13 Apr 2016, at 16:39, Eric Blake wrote: >> >> 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

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

Wouter, On 13 Apr 2016, at 12:44, Wouter Verhelst wrote: > Hi Alex, > > On Wed, Apr 13, 2016 at 11:25:02AM +0100, Alex Bligh wrote: >> Wouter, >> +A client MAY use a soft disconnect to terminate the session +whenever it wishes, provided that there are no outstanding

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

Hi Alex, On Wed, Apr 13, 2016 at 11:25:02AM +0100, 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

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

Eric, Agree with the nits - many of them were from the mailing list message which of course I then didn't check before copying into the commit message. Re the substance: >> +* Transmission mode can be entered (by the client sending >> + `NBD_OPT_EXPORT_NAME` or by the server responding to an

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On Tue, Apr 12, 2016 at 08:31:33PM +0100, Alex Bligh wrote: > Improve the documentation as per the mailing list discussion. > Here's what we deciced (broadly). > > * One side MAY drop the connection if the other end violates a > MUST condition. > > * The server MUST drop the connection in the

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On 04/12/2016 01:31 PM, Alex Bligh wrote: > Improve the documentation as per the mailing list discussion. > Here's what we deciced (broadly). s/deciced/decided/ > > * One side MAY drop the connection if the other end violates a > MUST condition. > > * The server MUST drop the connection in