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