qemu-block
[Top][All Lists]
Advanced

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

Re: Selecting meta context when calling NBD_CMD_BLOCK_STATUS


From: Richard W.M. Jones
Subject: Re: Selecting meta context when calling NBD_CMD_BLOCK_STATUS
Date: Thu, 26 Dec 2019 14:52:11 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Dec 26, 2019 at 04:29:03PM +0200, Nir Soffer wrote:
> Currently client need to use NBD_OPT_SET_META_CONTEXT during handshake to
> select the meta context it wants to get in NBD_CMD_BLOCK_STATUS.
> 
> This means that if you want to provide the option to get both
> "base:allocation" and
> "qemu:dirty-bitmap:x" using the same NBD client connection, you must
> pay for getting
> both during NBD_CMD_BLOCK_STATUS even if the user of the NBD client is not 
> going
> to use both.
> 
> Or, you can use new client connection for getting meta context not
> that the current
> client did not select, which require server that supports multiple
> connections, and new
> handshake. This seems to be more complicated than needed.

What's the problem with opening another connection?  Could it be
you're confusing this with the "multi-conn" capability which is
different?

Rich.

> This complicates existing clients:
> - qemu-img can return either "base:allocation" or
> "qemu:dirty-bitmap:x" using complex
>   undocumentde configuration
> - ovirt-imageio is using dirty flag in the client to enable both
> "base:allocation" and
>   "qemu:dirty-bitmap:x", so we can provide merged extents reporting
> both allocation
>   status and "dirtiness" for every extent.
> 
> Should we extend NBD_CMD_BLOCK_STATUS so we can specify list of meta context
> at the time of the call?
> 
> Looking at command structure, I don't think it could be extended. We
> need to specify
> list of 32 bit context ids, so we need something like:
> 
> 32 bits, length of payload (N * 4)
> 32 bits, contex id 1
> ...
> 32 bits, context id N
> 
> But the length field of a BLOCK_STATUS command is already used to
> specify the range
> of the reply.
> 
> So maybe add a new handshake flag, NBD_OPT_EXTENDED_COMMAND. If set during
> handshake, and NBD_FLAG_EXTENDED is set, a command will support
> additional payload
> like the list of context ids.
> 
> So a BLOCK_STATUS command will look like:
> 
> C: 32 bits, NBD_REQUEST_MAGIC)
> C: 16 bits, NBD_FLAG_EXTENDED
> C: 16 bits, NBD_CMD_BLOCK_STATUS
> C: 64 bits, 42
> C: 64 bits, 0
> C: 32 bits, 1073741824
> C: 32 bits: 4
> C: 32 bit: 1
> 
> With this the server reply will be only for context id 1.
> 
> What do you think?
> 
> Nir

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v




reply via email to

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