Re: [Libguestfs] Cross-project NBD extension proposal: NBD_INFO_INIT_STATE

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