Re: [Qemu-block] [RFC PATCH] protocol: Add NBD_CMD_FLAG_FAST_ZERO

[Eric Blake]

On 3/22/19 11:42 AM, Eric Blake wrote:

> 
> Hence, it is desirable to have a way for clients to specify that a
> particular write zero request is being attempted for a fast wipe, and
> get an immediate failure if the zero request would otherwise take the
> same time as a write.  Conversely, if the client is not performing a
> pre-initialization pass, it is still more efficient in terms of
> networking traffic to send NBD_CMD_WRITE_ZERO requests where the
> server implements the fallback to the slower write, than it is for the
> client to have to perform the fallback to send NBD_CMD_WRITE with a
> zeroed buffer.
> 
> Add a protocol flag and corresponding transmission advertisement flag
> to make it easier for clients to inform the server of their intent. If

Note that this is independent of proposals made on the NBD list in the
past [1] of having a way for the server to advertise that a particular
export starts in an all-zeroes state (faster than a series of 32-bit
NBD_CMD_BLOCK_STATUS would be able to do), although I may _also_ try to
revive proposed documentation and a reference implementation of that
optimization as well (as qemu-img convert can completely skip the
zeroing, whether the bulk wipe or per-hole writing, when it knows the
destination is already zero).

[1] https://lists.debian.org/nbd/2016/12/msg00015.html and following
(doc: Propose NBD_FLAG_INIT_ZEROES extension)

> 
> I will not push this without both:
> - a positive review (for example, we may decide that burning another
> NBD_FLAG_* is undesirable, and that we should instead have some sort
> of NBD_OPT_ handshake for determining when the server supports
> NBD_CMF_FLAG_FAST_ZERO)
> - a reference client and server implementation (probably both via qemu,
> since it was qemu that raised the problem in the first place)

The last time we mentioned the possibility of advertising an initial
zero state, we debated whether burning one of our 16 NBD_FLAG_*
transmission bits for that purpose was wise [2], but discussion stalled
after I never developed a counterproposal with NBD_OPT_* handshaking and
never produced a reference implementation.

[2] https://lists.debian.org/nbd/2016/12/msg00048.html

Also, keep in mind that knowing that something started as all zeroes
(which only affects startup; once you do any write, that early status
bit no longer means anything to current operation, so less important to
hand to the kernel during transmission phase, especially if the kernel
can ever learn to utilize NBD_CMD_BLOCK_STATUS) is indeed different from
knowing if probing for fast zeroing is supported (where it is easy to
conceive of the kernel needing to know if it can send
NBD_CMD_FLAG_FAST_ZERO).  So we may still want to use NBD_OPT_* to get
the initial zero extension, but NBD_FLAG to advertise the fast zero
extension.

On the other hand, it's also worth thinking about which extensions are
easy for servers to implement - NBD_FLAG_INIT_ZEROES and
NBD_FLAG_SEND_FAST_ZERO are orthogonal enough that I could see a full
2x2 mix of servers (unsupported, either one of the two supported, or
both supported), and where clients may make optimization choices based
on any of those four combinations.

[and if we're keeping score, other extension proposals that I want
revisit, in no particular order, include:
- 64-bit operations
- NBD_CMD_RESIZE
- more precision on TRIM/WRITE_ZERO alignment constraints
]

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature