[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross-project NBD extension proposal: NBD_INFO_INIT_STATE

From: Eric Blake
Subject: Re: Cross-project NBD extension proposal: NBD_INFO_INIT_STATE
Date: Tue, 11 Feb 2020 08:33:26 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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

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:


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]