diff mbox

[PULL,11/15] nbd: don't request FUA on FLUSH

Message ID 1459849818-26649-12-git-send-email-pbonzini@redhat.com
State New
Headers show

Commit Message

Paolo Bonzini April 5, 2016, 9:50 a.m. UTC 
From: Eric Blake <eblake@redhat.com>

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 <eblake@redhat.com>
Message-Id: <1459526902-32561-1-git-send-email-eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 block/nbd-client.c | 4 ----
 1 file changed, 4 deletions(-)
diff mbox

Patch

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;