Re: [Qemu-block] [PATCH] nbd/client: add x-block-status hack for testing server

[John Snow]

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 <address@hidden>
>> ---
>

signature.asc
Description: OpenPGP digital signature