[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: Wed, 12 Feb 2020 06:09:11 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/12/20 1:27 AM, Wouter Verhelst wrote:

On Mon, Feb 10, 2020 at 10:52:55PM +0000, Richard W.M. Jones wrote:
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:

Yeah, I think that could definitely be useful. I honestly can't see a
use for NBD_INIT_SPARSE as defined in this proposal; and I don't think
it's generally useful to have a feature if we can't think of a use case
for it (that creates added complexity for no benefit).

If we can find a reasonable use case for NBD_INIT_SPARSE as defined in
this proposal, then just add a third bit (NBD_INIT_ALL_SPARSE or
something) that says "the whole image is sparse". Otherwise, I think we
should redefine NBD_INIT_SPARSE to say that.

Okay, in v2, I will start with just two bits, NBD_INIT_SPARSE (entire image is sparse, nothing is allocated) and NBD_INIT_ZERO (entire image reads as zero), and save any future bits for later additions. Do we think that 16 bits is sufficient for the amount of initial information likely to be exposed? Are we in agreement that my addition of an NBD_INFO_ response to NBD_OPT_GO is the best way to expose initial state bits?

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]