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 r
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 immediately, but
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 wrote:
Wouter,
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.
I'm less opposed to SH
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 the session
>
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):
http://www.spinics.net/lists/linux-fsdevel/msg45584.html
Sp
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 commands in any orde
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 ac
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
+replies to
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 ti
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
>>
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, a
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 'n
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 the
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 'no way out' situations
during the negotiation phase (error on NBD_OPT_EXPO
15 matches
Mail list logo