Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752509AbcJCHVD (ORCPT ); Mon, 3 Oct 2016 03:21:03 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:33585 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751432AbcJCHUy (ORCPT ); Mon, 3 Oct 2016 03:20:54 -0400 Date: Mon, 3 Oct 2016 00:20:49 -0700 From: Christoph Hellwig To: Josef Bacik Cc: Alex Bligh , Wouter Verhelst , 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: <20161003072049.GA16847@infradead.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B49072B-6F83-4CD2-863B-5AB21E1F7816@fb.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 908 Lines: 12 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. 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.