Hi Eric!

I'm now testing my nbd block status realization (block_status part, not about dirty bitmaps), and faced into the following effect.


I created empty qcow2 image and wrote to the first sector, so

qemu-io -c map x

reports:

64 KiB (0x10000) bytes     allocated at offset 0 bytes (0x0)
9.938 MiB (0x9f0000) bytes not allocated at offset 64 KiB (0x10000)

But I can't get same results, when connecting to nbd server, exporting the same qcow2 file, I get

10 MiB (0xa00000) bytes     allocated at offset 0 bytes (0x0)


Finally, I understand the reason:

for local file, qemu-io calls bdrv_is_allocated, which calls bdrv_common_block_status_above with want_zero=false. So, it doesn't set BDRV_BLOCK_ZERO, and doesn't set BDRV_BLOCK_ALLOCATED. And, even if we change want_zero to true, here, it will set BDRV_BLOCK_ZERO, but will not set BDRV_BLOCK_ALLOCATED, which contradicts with it's definition:

 BDRV_BLOCK_ALLOCATED: the content of the block is determined by this
                       layer (short for DATA || ZERO), set by block layer


for nbd, we go through the similar way on server (but with want_zero = true), and we finally have BDRV_BLOCK_ZERO without BDRV_BLOCK_ALLOCATED, which maps to NBD_STATE_HOLE+NBD_STATE_ZERO. But then, in the client we have BDRV_BLOCK_ZERO not automatically added by block layer but directly from nbd driver, therefor BDRV_BLOCK_ALLOCATED is set and I get different result.


this all looks weird for me.

BDRV_BLOCK_ALLOCATED definition should be fixed, to show that this flag show only reported by driver flags, not automatically added.

And then the situation with nbd looks strange, because automatically added flag becomes "flag, reported by block driver".

On the other hand, it is not wrong.


I think, to test the feature, I'll improve qemu-io map, to show zeros (or is it better to add separate command?) and leave the other things as is. What do you think?

--
Best regards,
Vladimir


Reply via email to