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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

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@openvz.org> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]