On 4 Apr 2016, at 20:54, Denis V. Lunev <den@...2317...> 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).