On 04/04/2016 11:03 PM, Alex Bligh wrote: > On 4 Apr 2016, at 20:54, Denis V. Lunev <[email protected]> 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 ------------------------------------------------------------------------------ _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
