Re: [Qemu-devel] [PATCH for-2.6] nbd: don't request FUA on FLUSH

[Paolo Bonzini <pbonzini@redhat.com>]

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 <eblake@redhat.com>
> ---
>  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