Re: Cross-project NBD extension proposal: NBD_INFO_INIT_STATE

[Eric Blake]

On 2/17/20 9:13 AM, Max Reitz wrote:
> Hi,
>
> It’s my understanding that without some is_zero infrastructure for QEMU,
> it’s impossible to implement this flag in qemu’s NBD server.

You're right that we may need some more infrastructure before being able 
to decide when to report this bit in all cases.  But for raw files, that 
infrastructure already exists: does block_status at offset 0 and the 
entire image as length return status that the entire file is a hole. 
And for qcow2 files, it would not be that hard to teach a similar 
block_status request to report the entire image as a hole based on my 
proposed qcow2 autoclear bit tracking that the image still reads as zero.

> At the same time, I still haven’t understood what we need the flag for.
>
> As far as I understood in our discussion on your qemu series, there is
> no case where anyone would need to know whether an image is zero.  All > 
> practical cases involve someone having to ensure that some image is
> zero.  Knowing whether an image is zero can help with that, but that can
> be an implementation detail.
>
> For qcow2, the idea would be that there is some flag that remains true
> as long as the image is guaranteed to be zero.  Then we’d have some
> bdrv_make_zero function, and qcow2’s implementation would use this
> information to gauge whether there’s something to do as all.
>
> For NBD, we cannot use this idea directly because to implement such a
> flag (as you’re describing in this mail), we’d need separate is_zero
> infrastructure, and that kind of makes the point of “drivers’
> bdrv_make_zero() implementations do the right thing by themselves” moot.

We don't necessarily need a separate is_zero infrastructure if we can 
instead teach the existing block_status infrastructure to report that 
the entire image reads as zero.  You're right that clients that need to 
force an entire image to be zero won't need to directly call 
block_status (they can just call bdrv_make_zero, and let that worry 
about whether a block status call makes sense among its list of steps to 
try).  But since block_status can report all-zero status for some cases, 
it's not hard to use that for feeding the NBD bit.

However, there's a difference between qemu's block status (which is 
already typed correctly to return a 64-bit answer, even if it may need a 
few tweaks for clients that currently don't expect it to request more 
than 32 bits) and NBD's block status (which can only report 32 bits 
barring a new extension to the protocol), and where a single all-zero 
bit at NBD_OPT_GO is just as easy of an extension as a way to report a 
64-bit all-zero response to NBD_CMD_BLOCK_STATUS.

> OTOH, we wouldn’t need such a flag for the implementation, because we
> could just send a 64-bit discard/make_zero over the whole block device
> length to the NBD server, and then the server internally does the right
> thing(TM).  AFAIU discard and write_zeroes currently have only 32 bit
> length fields, but there were plans for adding support for 64 bit
> versions anyway.  From my naïve outsider perspective, doing that doesn’t
> seem a more complicated protocol addition than adding some way to tell
> whether an NBD export is zero.

Adding 64-bit commands to NBD is more invasive than adding a single 
startup status bit.  Both ideas can be done - doing one does not 
preclude the other.  But at the same time, not all servers will 
implement both ideas - if one is easy to implement while the other is 
hard, it is not unlikely that qemu will still encounter NBD servers that 
advertise startup state but not support 64-bit make_zero (even if qemu 
as NBD server starts supporting 64-bit make zero) or even 64-bit block 
status results.

Another thing to think about here is timing.  With the proposed NBD 
addition, it is the server telling the client that "the image you are 
connecting to started zero", prior to the point that the client even has 
a chance to request "can you make the image all zero in a quick manner 
(and if not, I'll fall back to writing zeroes as I go)".  And even if 
NBD gains a 64-bit block status and/or make zero command, it is still 
less network traffic for the server to advertise up-front that the image 
is all zero than it is for the client to have to issue command requests 
of the server (network traffic is not always the bottleneck, but it can 
be a consideration).

> So I’m still wondering whether there are actually cases where we need to
> tell whether some image or NBD export is zero that do not involve making
> it zero if it isn’t.

Just because we don't think that qemu-img has such a case does not mean 
that other NBD clients will not be able to come up with some use for 
knowing if an image starts all zero.

> (I keep asking because it seems to me that if all we ever really want to
> do is to ensure that some images/exports are zero, we should implement
> that.)

The problem is WHERE do you implement it.  Is it more efficient to 
implement make_zero in the NBD server (the client merely requests to 
make zero, but lets the server do all the work) or in the NBD client 
(the client learns whether the server is already zero, and not hearing 
yes, the client proceeds to do all the work to write zeroes).  From the 
qemu perspective, qemu-img convert needs the image to be zero, and 
bdrv_make_zero will report back either "yes I quickly made it zero, 
possibly by doing nothing" or "no, making it zero now is no more 
efficient than you just writing zeroes as you go".  But although the 
code in qemu-img is the same whether bdrv_make_zero is able to request 
the work be done in the server or whether the work has to be done in the 
client, the code in the block layer that implements bdrv_make_zero may 
itself care about knowing whether the NBD server started all zero.

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