Re: [Nbd] [PATCH][V3] nbd: add multi-connection support

On Oct 2, 2016, at 12:17 PM, Alex Bligh [off-list ref] wrote:
=20
=20

quoted

On 29 Sep 2016, at 17:59, Josef Bacik [off-list ref] wrote:
=20
On 09/29/2016 12:41 PM, Wouter Verhelst wrote:

quoted

quoted

On Thu, Sep 29, 2016 at 10:03:50AM -0400, Josef Bacik wrote:
So think of it like normal disks with multiple channels.  We don't sen=

d flushes

quoted

quoted

quoted

down all the hwq's to make sure they are clear, we leave that decision=

 up to the

quoted

quoted

quoted

application (usually a FS of course).

=20
Well, when I asked earlier, Christoph said[1] that blk-mq assumes that
when a FLUSH is sent over one channel, and the reply comes in, that all
commands which have been received, regardless of which channel they wer=

e

quoted

quoted

received over, have reched disk.
=20
[1] Message-ID: [ref]
=20
It is impossible for nbd to make such a guarantee, due to head-of-line
blocking on TCP.
=20

=20
Huh I missed that.  Yeah that's not possible for us for sure, I think my=

 option=20

quoted

idea is the less awful way forward if we want to address that limitation=

.  Thanks,

=20
I think if the server supports flush (which you can tell), sending flush =

on

all channels is the only safe thing to do, without substantial protocol
changes (which I'm not sure how one would do given flush is in a sense
a synchronisation point). I think it's thus imperative this gets fixed
before the change gets merged.

It's not "broken", it's working as designed, and any fs on top of this patc=
h will be perfectly safe because they all wait for their io to complete bef=
ore issuing the FLUSH.  If somebody wants to address the paranoid case late=
r then all the power to them, but this works for my use case and isn't inhe=
rently broken.  If it doesn't work for yours then don't use the feature, it=
's that simple.  Thanks,

Josef=