From patchwork Fri Apr 1 16:08:22 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 8726481 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 25A51C0553 for ; Fri, 1 Apr 2016 16:10:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7CCBA20390 for ; Fri, 1 Apr 2016 16:10:48 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AF7FE20303 for ; Fri, 1 Apr 2016 16:10:47 +0000 (UTC) Received: from localhost ([::1]:45372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am1eo-0006Aw-UI for patchwork-qemu-devel@patchwork.kernel.org; Fri, 01 Apr 2016 12:10:46 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am1ee-000699-LB for qemu-devel@nongnu.org; Fri, 01 Apr 2016 12:10:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1am1eZ-0001LW-Id for qemu-devel@nongnu.org; Fri, 01 Apr 2016 12:10:36 -0400 Received: from resqmta-po-04v.sys.comcast.net ([96.114.154.163]:52100) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am1eZ-0001LQ-Aa for qemu-devel@nongnu.org; Fri, 01 Apr 2016 12:10:31 -0400 Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by comcast with SMTP id m1biaNghvIY3Mm1cca4gbw; Fri, 01 Apr 2016 16:08:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459526910; bh=Xy+zONUiiuCPHP3mqUkKn6fVwQ/qmR2Nt41eoqH0DCs=; h=Received:Received:From:To:Subject:Date:Message-Id; b=LKEYl3F+7KBOkSdg9P+ndRIcuRb3VgJydL80LqOCizILdSPFmDERZCHilwpMLGT+O N8IsGUsTK62P0+ysQU63LXU0GhQT2FdHgSEa69xwvyCzyOI27bwB1P/kzfI0/oNskn 4Wlh1MBRe+SaASXdzJX2PWjfzdo8BeDbKzuu2/RfOvX6DFiCOcyJBaqIf2BF5U6R7u 9ox50MnC5QP1TRlGo9vQEw5qybSbloPRj5ZEv1RPFKmBIQiOz+839tm2wD6eB2OmFe NDueiPOCwrizjiKhhLHuPEtcdeBVfVSGUhOoroGl4DrdVxzIRGB+JoIxbvhKPikf9V Tkt+awPyMOj6A== Received: from red.redhat.com ([24.10.254.122]) by resomta-po-10v.sys.comcast.net with comcast id d48T1s00C2fD5rL0148WBF; Fri, 01 Apr 2016 16:08:30 +0000 From: Eric Blake To: qemu-devel@nongnu.org Date: Fri, 1 Apr 2016 10:08:22 -0600 Message-Id: <1459526902-32561-1-git-send-email-eblake@redhat.com> X-Mailer: git-send-email 2.5.5 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.114.154.163 Cc: Kevin Wolf , pbonzini@redhat.com, "open list:Block layer core" Subject: [Qemu-devel] [PATCH for-2.6] nbd: don't request FUA on FLUSH X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The NBD protocol does not clearly document what will happen if a client sends NBD_CMD_FLAG_FUA on NBD_CMD_FLUSH. Historically, both the qemu and upstream NBD servers silently ignored that flag, but that feels a bit risky. Meanwhile, the qemu NBD client unconditionally sends the flag (without even bothering to check whether the caller cares; at least with NBD_CMD_WRITE the client only sends FUA if requested by a higher layer). There is ongoing discussion on the NBD list to fix the protocol documentation to require that the server MUST ignore the flag (unless the kernel folks can better explain what FUA means for a flush), but until those doc improvements land, the current nbd.git master was recently changed to reject the flag with EINVAL (see nbd commit ab22e082), which now makes it impossible for a qemu client to use FLUSH with an upstream NBD server. We should not send FUA with flush unless the upstream protocol documents what it will do, and even then, it should be something that the caller can opt into, rather than being unconditional. Signed-off-by: Eric Blake --- block/nbd-client.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/block/nbd-client.c b/block/nbd-client.c index 021a88b..878e879 100644 --- a/block/nbd-client.c +++ b/block/nbd-client.c @@ -319,10 +319,6 @@ int nbd_client_co_flush(BlockDriverState *bs) return 0; } - if (client->nbdflags & NBD_FLAG_SEND_FUA) { - request.type |= NBD_CMD_FLAG_FUA; - } - request.from = 0; request.len = 0;