On 06/25/2018 09:50 AM, Max Reitz wrote: > 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 >
I'm not sure we actually want to check this in even temporarily, but we
do need to make use of it as a debugging facility in the meantime.
As such, x-debug- works perfectly well, but it may not matter.
--js
>> 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
