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/0670fc20df4a4bbbeb0edb30d82628ea30a8...
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