qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-block] [PATCH 0/4] Support larger NBD_CMD_WRITE_ZEROES


From: Eric Blake
Subject: [Qemu-block] [PATCH 0/4] Support larger NBD_CMD_WRITE_ZEROES
Date: Tue, 1 May 2018 16:13:32 -0500

This is my counterproposal for:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02107.html
where Edgar pointed out that NBD write zero requests are rather
inefficient because the NBD spec was ambiguous on whether we could
exceed an advertised maximum request size even when the command
carries no payload, and so for maximum compatibility with unknown
NBD partners, we erred on the conservative side.

The NBD spec has since been improved to mention that a client can
try a larger WRITE_ZEROES if it is prepared to handle an EINVAL, and
that a server should not hang up on overlarge requests that did not
include a payload.  But in the process it was pointed out that even
better would be improving the spec to advertise both limits (the
READ/WRITE payload limit, and the larger TRIM/ZERO limit), as done
in this series.

With this in place, qemu as both NBD client and server can send
zero requests up to BDRV_REQUEST_MAX_BYTES (nearly 2G) in length,
rather than having to subdivide the request into 32M chunks.

This series is experimental until the NBD spec is actually modified
to document the feature added here; but that modification will be
easier now that I have a proof-of-concept implementation.

Eric Blake (4):
  nbd: Prepare for additional block sizing info
  nbd/client: Refactor in preparation for more limits
  nbd/client: Support requests of additional block sizing info
  nbd/server: Support requests of additional block sizing info

 include/block/nbd.h |   8 +++-
 block/nbd.c         |  15 +++++-
 nbd/client.c        | 135 +++++++++++++++++++++++++++++++++++++++++++++++-----
 nbd/common.c        |   4 ++
 nbd/server.c        |  30 ++++++++++++
 nbd/trace-events    |   4 ++
 6 files changed, 181 insertions(+), 15 deletions(-)

-- 
2.14.3




reply via email to

[Prev in Thread] Current Thread [Next in Thread]