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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2B49072B-6F83-4CD2-863B-5AB21E1F7816@fb.com>
Date:   Mon, 3 Oct 2016 01:47:06 +0000
From:   Josef Bacik <jbacik@...com>
To:     Alex Bligh <alex@...x.org.uk>
CC:     Wouter Verhelst <w@...r.be>, Jens Axboe <axboe@...com>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>,
        "nbd-general@...ts.sourceforge.net" 
        <nbd-general@...ts.sourceforge.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Nbd] [PATCH][V3] nbd: add multi-connection support


> On Oct 2, 2016, at 12:17 PM, Alex Bligh <alex@...x.org.uk> wrote:
> 
> 
>> On 29 Sep 2016, at 17:59, Josef Bacik <jbacik@...com> wrote:
>> 
>> On 09/29/2016 12:41 PM, Wouter Verhelst wrote:
>>>> 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 send flushes
>>>> down all the hwq's to make sure they are clear, we leave that decision up to the
>>>> application (usually a FS of course).
>>> 
>>> 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 were
>>> received over, have reched disk.
>>> 
>>> [1] Message-ID: <20160915122304.GA15501@...radead.org>
>>> 
>>> It is impossible for nbd to make such a guarantee, due to head-of-line
>>> blocking on TCP.
>>> 
>> 
>> Huh I missed that.  Yeah that's not possible for us for sure, I think my option 
>> idea is the less awful way forward if we want to address that limitation.  Thanks,
> 
> 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 patch will be perfectly safe because they all wait for their io to complete before issuing the FLUSH.  If somebody wants to address the paranoid case later then all the power to them, but this works for my use case and isn't inherently broken.  If it doesn't work for yours then don't use the feature, it's that simple.  Thanks,

Josef