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
