On 04/04/2016 02:27 PM, Denis V. Lunev wrote: > On 04/04/2016 11:15 PM, Alex Bligh wrote: >> On 4 Apr 2016, at 21:13, Denis V. Lunev <den@...2317...> wrote: >> >>> As far as I remember that text we have had a number in request >>> specifying which bitmap to query and the server should reply with one >>> bitmap at a time. >>> >>> Would this work for you? >> I think that would be much better, yes, though I'd suggest the >> bitmap had an ID other than a number 0..15 so other people >> can use it too. >> > bitmap requires to negotiate granularity which is > not that easy thing. > > If we have different granularities for 'dirty' and 'allocated' > bitmaps and we can report this using this proto and > can not do this cleanly with bitmap approach assuming > that we will add 'NBD_STATE_DIRTY_DEALLOCATED' (0x2) state I'm not sure what you are trying to propose adding here. 'state' is a bitmap - it is either a representation of two bits of information (NBD_CMD_FLAG_DIRTY was clear, so state is the bitwise OR of NBD_STATE_HOLE and NBD_STATE_ZERO), or the representation of one bit of information (NBD_CMD_FLAG_DIRTY was set, so state is the bitwise OR of NBD_STATE_CLEAN). I'm not sure where you are reading into this that granularity has to be negotiated. The client never mentions granularity; and the server is perfectly free to report data in descriptors as large or as small as it wants (although I did document that the server SHOULD stick to descriptors that are at least 512 bytes at a time, and SHOULD coalese descriptors so that two consecutive descriptors have distinct state values). Whether something is allocated or not has no direct bearing on whether it is dirty or not; and it is feasible that a server could report the act of NBD_CMD_TRIM as causing a portion of the file to become dirty. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature