[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH for-2.6] nbd: don't request FUA on FLUSH
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-block] [PATCH for-2.6] nbd: don't request FUA on FLUSH |
Date: |
Mon, 4 Apr 2016 09:34:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
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 <address@hidden>
> ---
> 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