Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752384AbcJCHwX (ORCPT ); Mon, 3 Oct 2016 03:52:23 -0400 Received: from latin.grep.be ([46.4.76.168]:54887 "EHLO latin.grep.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752200AbcJCHwH (ORCPT ); Mon, 3 Oct 2016 03:52:07 -0400 Date: Mon, 3 Oct 2016 09:51:49 +0200 From: Wouter Verhelst To: Christoph Hellwig Cc: Josef Bacik , Alex Bligh , Jens Axboe , "linux-block@vger.kernel.org" , Kernel Team , "nbd-general@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" Subject: Re: [Nbd] [PATCH][V3] nbd: add multi-connection support Message-ID: <20161003075149.u3ppcnk2j55fci6h@grep.be> References: <1475092892-8230-1-git-send-email-jbacik@fb.com> <20160929095204.mexr6wpypo3bl6mx@grep.be> <87908d95-0b7c-bc3f-f69d-94d006829daf@fb.com> <20160929164100.akytbkbtvziwaqqj@grep.be> <2B49072B-6F83-4CD2-863B-5AB21E1F7816@fb.com> <20161003072049.GA16847@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161003072049.GA16847@infradead.org> X-Speed: Gates' Law: Every 18 months, the speed of software halves. Organization: none User-Agent: NeoMutt/20160916 (1.7.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1851 Lines: 38 On Mon, Oct 03, 2016 at 12:20:49AM -0700, Christoph Hellwig wrote: > On Mon, Oct 03, 2016 at 01:47:06AM +0000, Josef Bacik wrote: > > 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, > > Let's take one step back here. I agree with Josef that sending > one single flush is perfectly fine for all usual cases. The issue > that was brought up last time we had this discussion was that some > (I think mostly theoretical) backends could not be coherent and > this would be an issue. Actually, I was pointing out the TCP head-of-line issue, where a delay on the socket that contains the flush reply would result in the arrival in the kernel block layer of a write reply before the said flush reply, resulting in a write being considered part of the flush when in fact it was not. This is an edge case, and one highly unlikely to result in problems in the common case (as per my other mail), but it is something to consider. > So maybe the right way is to simply not support the current odd flush > defintion in the kernel then and require a new properly defined flush > version instead. Can you clarify what you mean by that? Why is it an "odd flush definition", and how would you "properly" define it? Thanks, -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12