On 2018-06-21 05:25, Eric Blake wrote: > In order to test that the NBD server is properly advertising > dirty bitmaps, we need a bare minimum client that can request > and read the context. This patch is a hack (hence the use of > the x- prefix) that serves two purposes: first, it lets the > client pass a request of more than one context at a time to > the server, to test the reaction of the server to various > contexts (via the list command). Second, whatever the first > context in the user's list becomes the context wired up to the > results visible in bdrv_block_status(); this has the result > that if you pass in 'qemu:dirty-bitmap:b' instead of the usual > 'base:allocation', and the server is currently serving a named > bitmap 'b', then commands like 'qemu-img map' now output status > corresponding to the dirty bitmap (dirty sections look like > holes, while clean sections look like data, based on how the > status bits are mapped over the NBD protocol). > > Since the hack corrupts the meaning of bdrv_block_status(), I > would NOT try to run 'qemu-img convert' or any other program > that might misbehave based on thinking clusters have a different > status than what the normal 'base:allocation' would provide. > > The hack uses a semicolon-separated list embedded in a single > string, as that was easier to wire into the nbd block driver than > figuring out the right incantation of flattened QDict to represent > an array via the command line. Oh well, just one more reason that > this hack deserves the 'x-' prefix.
Without having looked at the patch, would an "x-debug-" prefix work
better? We have that for x-debug-block-dirty-bitmap-sha256. The reason
is that just "x-" means "experimental", which at least to me implies
"once we have done all of our experiments, it will no longer be
experimental and the prefix is dropped". "x-debug-" means that it is
actually not experimental, but just a debugging interface that will
never be stable.
(Yes, I know we haven't documented the meaning of x-debug- anywhere...)
Max
> As a demo, I was able to prove things work with the following sequence:
>
> $ qemu-img info file
> image: file
> file format: qcow2
> virtual size: 2.0M (2097152 bytes)
> disk size: 2.0M
> cluster_size: 65536
> Format specific information:
> compat: 1.1
> lazy refcounts: false
> refcount bits: 16
> corrupt: false
>
> $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio
> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
> "package": "v2.12.0-1531-g3ab98aa673d"}, "capabilities": []}}
> {'execute':'qmp_capabilities'}
> {"return": {}}
> {'execute':'blockdev-add','arguments':{'driver':'qcow2','node-name':'n','file':{'driver':'file','filename':'file'}}}
> {"return": {}}
> {'execute':'block-dirty-bitmap-add','arguments':{'node':'n','name':'b','persistent':true}}
> {"return": {}}
> {'execute':'quit'}
> {"return": {}}
> {"timestamp": {"seconds": 1529548814, "microseconds": 472828}, "event":
> "SHUTDOWN", "data": {"guest": false}}
>
> $ ./qemu-io -f qcow2 file
> qemu-io> r -v 0 1
> 00000000: 01 .
> read 1/1 bytes at offset 0
> 1 bytes, 1 ops; 0.0001 sec (4.957 KiB/sec and 5076.1421 ops/sec)
> qemu-io> w -P 1 0 1
> wrote 1/1 bytes at offset 0
> 1 bytes, 1 ops; 0.0078 sec (127.502231 bytes/sec and 127.5022 ops/sec)
> qemu-io> q
>
> $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio
> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
> "package": "v2.12.0-1531-g3ab98aa673d"}, "capabilities": []}}
> {'execute':'qmp_capabilities'}
> {"return": {}}
> {'execute':'nbd-server-start','arguments':{'addr':{'type':'inet','data':{'host':'localhost','port':'10809'}}}}
> {"return": {}}
> {'execute':'blockdev-add','arguments':{'driver':'qcow2','node-name':'n','file':{'driver':'file','filename':'file'}}}
> {"return": {}}
> {'execute':'nbd-server-add','arguments':{'device':'n'}}
> {"return": {}}
> {'execute':'x-nbd-server-add-bitmap','arguments':{'name':'n','bitmap':'b'}}
> {"error": {"class": "GenericError", "desc": "Bitmap 'b' is enabled"}}
> {'execute':'x-block-dirty-bitmap-disable','arguments':{'node':'n','name':'b'}}
> {"return": {}}
> {'execute':'x-nbd-server-add-bitmap','arguments':{'name':'n','bitmap':'b'}}
> {"return": {}}
> ... leave running
>
> $ ./qemu-img map --output=json --image-opts
> driver=nbd,export=n,server.type=inet,server.host=localhost,server.port=10809
> [{ "start": 0, "length": 1114112, "depth": 0, "zero": false, "data": true},
> { "start": 1114112, "length": 458752, "depth": 0, "zero": true, "data":
> false},
> { "start": 1572864, "length": 524288, "depth": 0, "zero": false, "data":
> true}]
>
> $ ./qemu-img map --output=json --image-opts
> driver=nbd,export=n,server.type=inet,server.host=localhost,server.port=10809,x-block-status=qemu:dirty-bitmap:b
> [{ "start": 0, "length": 65536, "depth": 0, "zero": false, "data": false},
> { "start": 65536, "length": 2031616, "depth": 0, "zero": false, "data": true}]
>
> The difference between the two runs shows that base:allocation status
> is thus different from the contents of dirty bitmap 'b'; and that the
> dirty bitmap 'b' indeed tracked the first 64k of the file as being
> dirty due to the qemu-io write at offset 0 performed between the creation
> of bitmap b in the first qemu, and the disabling it prior to exporting it
> in the second qemu.
>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
> ---
signature.asc
Description: OpenPGP digital signature
