Re: [Libguestfs] [RFC PATCH] protocol: Add NBD_CMD_FLAG_FAST_ZERO

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_CMD_FLAG_FAST_ZERO)

From an implementation point of view I prefer simple flags over having

> - 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 ]