search for: nbd_info_init_state

See the cross-posted cover letter for more details. Eric Blake (10): protocol: Add NBD_INFO_INIT_STATE extension protocol: Wire up backend support for NBD_INFO_INIT_STATE filters: Wire up filter support for NBD_INFO_INIT_STATE plugins: Wire up in-memory plugin support for NBD_INFO_INIT_STATE plugins: Wire up file-based plugin support for NBD_INFO_INIT_STATE plugins: Wire up shell plugin su...

...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). I guess given those constraints we can stick with 16 feature bits, and if we ever needed more then we'd ha...

...39;t allow the client to configure which infos to + * request, but instead rely on what the server volunteers. */ h->sbuf.nrinfos = 0; h->wbuf = &h->sbuf; h->wlen = 2; @@ -130,6 +132,14 @@ STATE_MACHINE { return 0; } break; + case NBD_INFO_INIT_STATE: + if (len != sizeof h->sbuf.or.payload.init) { + SET_NEXT_STATE (%.DEAD); + set_error (0, "handshake: incorrect NBD_INFO_INIT_STATE option reply length"); + return 0; + } + h->initflags = be16toh (h->sbuf.or.payload.init.flags); +...

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

The idea and patch is fine, but I wonder if it would be more useful to callers if it was exposed as two separate APIs. Callers would then not need to deal with masking out unknown flags, and it works more like the other is_* / can_* ("flag calls") we already have. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and

On 2/10/20 4:24 PM, Richard W.M. Jones wrote: > > The idea and patch is fine, but I wonder if it would be more useful to > callers if it was exposed as two separate APIs. Callers would then > not need to deal with masking out unknown flags, and it works more > like the other is_* / can_* ("flag calls") we already have. Fair point, especially since I exposed it in nbdkit

The NBD protocol is adding an extension to let servers advertise initialization state to the client: whether the image contains holes, and whether it is known to read as all zeroes. With recent enough libnbd, the nbd plugin can pass this information through. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/nbd/nbd.c | 40 +++++++++++++++++++++++++++++++++++++++- 1 file changed,

On Mon, Feb 10, 2020 at 03:43:56PM -0600, Eric Blake wrote: > diff --git a/filters/noextents/noextents.c b/filters/noextents/noextents.c > index e6ac33b..091f30b 100644 > --- a/filters/noextents/noextents.c > +++ b/filters/noextents/noextents.c > @@ -1,5 +1,5 @@ > /* nbdkit > - * Copyright (C) 2019 Red Hat Inc. > + * Copyright (C) 2019-2020 Red Hat Inc. > * > *

On Mon, Feb 10, 2020 at 03:43:57PM -0600, Eric Blake wrote: > +/* Does current client start with a sparse image. */ > +static int > +memory_init_sparse (void *handle) > +{ > + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); > + return sparse_array_is_sparse (sa); > +} > + > +/* Does current client start with all zeroes. */ > +static int > +memory_init_zero (void

On Mon, Feb 10, 2020 at 03:43:58PM -0600, Eric Blake wrote: > @@ -214,6 +217,52 @@ file_open (int readonly) > h->can_fallocate = true; > h->can_zeroout = h->is_block_device; > > + h->can_extents = false; > + h->init_sparse = false; > + h->init_zero = false; > +#ifdef SEEK_HOLE > + if (!h->is_block_device) { > + off_t r; > + > +

On 2/12/20 1:27 AM, Wouter Verhelst wrote: > Hi, > > 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: > >

Hi, It’s my understanding that without some is_zero infrastructure for QEMU, it’s impossible to implement this flag in qemu’s NBD server. At the same time, I still haven’t understood what we need the flag for. As far as I understood in our discussion on your qemu series, there is no case where anyone would need to know whether an image is zero. All practical cases involve someone having to

Hi, 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

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

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

I will be following up to this email with four separate threads each addressed to the appropriate single list, with proposed changes to: - the NBD protocol - qemu: both server and client - libnbd: client - nbdkit: server The feature in question adds a new optional NBD_INFO_ packet to the NBD_OPT_GO portion of handshake, adding up to 16 bits of information that the server can advertise to the

On 2/17/20 9:13 AM, Max Reitz wrote: > Hi, > > It’s my understanding that without some is_zero infrastructure for QEMU, > it’s impossible to implement this flag in qemu’s NBD server. You're right that we may need some more infrastructure before being able to decide when to report this bit in all cases. But for raw files, that infrastructure already exists: does block_status at

The NBD protocol is adding an extension to let servers advertise initialization state to the client: whether the image contains holes, and whether it is known to read as all zeroes. For file-based plugins, we are already probing lseek(SEEK_HOLE) to learn if extents are supported; a slight tweak to remember if that result is EOF tells us if we are sparse, and a similar lseek(SEEK_DATA) returning

The NBD protocol is adding an extension to let servers advertise initialization state to the client: whether the image contains holes, and whether it is known to read as all zeroes. Most filters just pass through the plugin's result (as it is only checked once when first connecting), but we can do useful things in log (mention the setting), extentlist (answer based on the extents we are

The NBD protocol is adding an extension to let servers advertise initialization state to the client: whether the image contains holes, and whether it is known to read as all zeroes. For memory-based plugins, it is fairly easy to advertise several cases: data and memory are usually sparse and detecting zero is easy (requires new functions to the sparse_array common code), although since the sparse