From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amz1b-0000Cq-HM for qemu-devel@nongnu.org; Mon, 04 Apr 2016 03:34:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1amz1a-0008UL-FM for qemu-devel@nongnu.org; Mon, 04 Apr 2016 03:34:15 -0400 Sender: Paolo Bonzini References: <1459526902-32561-1-git-send-email-eblake@redhat.com> From: Paolo Bonzini Message-ID: <570218EF.4040302@redhat.com> Date: Mon, 4 Apr 2016 09:34:07 +0200 MIME-Version: 1.0 In-Reply-To: <1459526902-32561-1-git-send-email-eblake@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.6] nbd: don't request FUA on FLUSH List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , "open list:Block layer core" On 01/04/2016 18:08, Eric Blake wrote: > 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; > Thanks, queued for 2.6. Paolo