> On Oct 2, 2016, at 12:17 PM, Alex Bligh <a...@alex.org.uk> wrote: > > >> On 29 Sep 2016, at 17:59, Josef Bacik <jba...@fb.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.ga15...@infradead.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-- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
