Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

["Denis V. Lunev" <den@openvz.org>]

On 04/04/2016 11:03 PM, Alex Bligh wrote:
> On 4 Apr 2016, at 20:54, Denis V. Lunev <den@openvz.org> wrote:
>
>> for now and for QEMU we want this to expose accumulated dirtiness
>> of the block device, which is collected by the server. Yes, this requires
>> external coordination. May be this COULD be the part of the protocol,
>> but QEMU will not use that part of the protocol.
>>
>> saying about dirtiness, we would soon come to the fact, that
>> we can have several dirtiness states regarding different
>> lines of incremental backups. This complexity is hidden
>> inside QEMU and it would be very difficult to publish and
>> reuse it.
> So qemu-nbdserver has some idea of 'dirtiness', and you want
> to publish that, and the consumer is qemu (and only qemu),
> because only qemu knows what 'dirtiness' means in the
> sense the server provides it?
>
> I've nothing against helping qemu out here (having
> contributed to qemu myself), but perhaps it might be better then,
> rather than call it 'dirtiness' to make it some named attribute
> for private client/server communication.
>
> This again makes me think this should be a different
> command from something which is obviously useful and
> comprehensible to more than one server/client (i.e.
> allocation).
>
original design of this command has used 16 number
to specify the NUMBER of the bitmap which was
exported by the server.

We have reserved number 0 for 'used' bitmap, i.e.
bitmap of allocated blocks and number 1 for 'dirty'
bitmap. Though we can skip specification of the
belonging of any number except '0' and put them
to server-client negotiations. Or we could reserve
'1' for dirtiness state as server-client agrees and
allow other applications to register their own bitmaps
as the deserve to.

Why not to do things this original way?

Den