Re: Cross-project NBD extension proposal: NBD_INFO_INIT_STATE

[Eric Blake <eblake@redhat.com>]

On 2/10/20 4:52 PM, Richard W.M. Jones wrote:
> On Mon, Feb 10, 2020 at 04:29:53PM -0600, Eric Blake wrote:
>> On 2/10/20 4:12 PM, Richard W.M. Jones wrote:
>>> On Mon, Feb 10, 2020 at 03:37:20PM -0600, Eric Blake wrote:
>>>> For now, only 2 of those 16 bits are defined: NBD_INIT_SPARSE (the
>>>> image has at least one hole) and NBD_INIT_ZERO (the image reads
>>>> completely as zero); the two bits are orthogonal and can be set
>>>> independently, although it is easy enough to see completely sparse
>>>> files with both bits set.
>>>
>>> I think I'm confused about the exact meaning of NBD_INIT_SPARSE.  Do
>>> you really mean the whole image is sparse; or (as you seem to have
>>> said above) that there exists a hole somewhere in the image but we're
>>> not saying where it is and there can be non-sparse parts of the image?
>>
>> As implemented:
>>
>> NBD_INIT_SPARSE - there is at least one hole somewhere (allocation
>> would be required to write to that part of the file), but there may
>> b allocated data elsewhere in the image.  Most disk images will fit
>> this definition (for example, it is very common to have a hole
>> between the MBR or GPT and the first partition containing a file
>> system, or for file systems themselves to be sparse within the
>> larger block device).
> 
> I think I'm still confused about why this particular flag would be
> useful for clients (I can completely understand why clients need
> NBD_INIT_ZERO).
> 
> But anyway ... could a flag indicating that the whole image is sparse
> be useful, either as well as NBD_INIT_SPARSE or instead of it?  You
> could use it to avoid an initial disk trim, which is something that
> mke2fs does:
> 
>    https://github.com/tytso/e2fsprogs/blob/0670fc20df4a4bbbeb0edb30d82628ea30a80598/misc/mke2fs.c#L2768

I'm open to suggestions on how many initial bits should be provided.  In 
fact, if we wanted, we could have a pair mutually-exclusive bits, 
advertising:
00 - no information known
01 - image is completely sparse
10 - image is completely allocated
11 - error

The goal of providing a 16-bit answer (or we could mandate 32 or 64 
bits, if we think we will ever want to extend that far) was to make it 
easier to add in whatever other initial-state extensions that someone 
could find useful.  Until we're happy with the design, the size or any 
given bit assignment is not locked down; once we do start committing any 
of this series, we've locked in what interoperability will demand but 
still have spare bits as future extensions.

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