[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:47:24 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/12/20 6:36 AM, Richard W.M. Jones wrote:

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?

So as I understand the proposal, the 16 bit limit comes about because
we want a round 4 byte reply, 16 bits are used by NBD_INFO_INIT_STATE
and that leaves 16 bits feature bits.  Therefore the only way to go
from there is to have 32 feature bits but an awkward unaligned 6 byte
structure, or 48 feature bits (8 byte structure).

In general, the NBD protocol has NOT focused on alignment issues (for good or for bad). For example, NBD_INFO_BLOCK_SIZE is 18 bytes; all NBD_CMD_* 32-bit requests are 28 bytes except for NBD_CMD_WRITE which can send unaligned payload with no further padding, and so forth.

I guess given those constraints we can stick with 16 feature bits, and
if we ever needed more then we'd have to introduce NBD_INFO_INIT_STATE2.

The only thing I can think of which might be useful is a "fully
preallocated" bit which might be used as an indication that writes are
fast and are unlikely to fail with ENOSPC.

and which would be mutually-exclusive with NBD_INFO_SPARSE (except for an image of size 0). That bit would ALSO be an indication that the user may not want to punch holes into the image, but preserve the fully-allocated state (and thus avoid NBD_CMD_TRIM as well as passing NBD_CMD_FLAG_NO_HOLE to any WRITE_ZEROES request).

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?

Seems reasonable to me.


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]