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

2016-12-08 Thread Alex Bligh
> On 8 Dec 2016, at 06:58, Vladimir Sementsov-Ogievskiy > wrote: > > An idea: let's not use uppercase. Why to shout the namespace? 'base' and 'x-' > would be better I think. BASE and X- will provoke all user-defined namespaces > be in uppercase too and a lot of

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

2016-12-07 Thread Vladimir Sementsov-Ogievskiy
08.12.2016 06:39, Alex Bligh wrote: [...] are vendor dependent extensions. The 'BASE' namespace represents metadata contexts defined within this document. Other namespaces may be registered by reference within this document. +The "BASE:allocation" Backticks: `BASE:allocation` An idea:

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

2016-12-07 Thread Alex Bligh
> On 2 Dec 2016, at 18:45, Alex Bligh wrote: > > Thanks. That makes sense - or enough sense for me to carry on commenting! I finally had some time to go through this extension in detail. Rather than comment on all the individual patches, I squashed them into a single commit,

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

2016-12-05 Thread Vladimir Sementsov-Ogievskiy
02.12.2016 23:39, John Snow wrote: On 12/02/2016 01:45 PM, Alex Bligh wrote: John, +Some storage formats and operations over such formats express a +concept of data dirtiness. Whether the operation is block device +mirroring, incremental block device backup or any other operation with +a

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

2016-12-03 Thread Alex Bligh
> On 2 Dec 2016, at 20:39, John Snow wrote: > > OK. We do certainly support multiple bitmaps being active at a time in > QEMU, but I had personally always envisioned that you'd associate them > one-at-a-time when starting the NBD export of a particular device. > > I don't

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

2016-12-02 Thread John Snow
On 12/02/2016 01:45 PM, Alex Bligh wrote: > John, > >>> +Some storage formats and operations over such formats express a >>> +concept of data dirtiness. Whether the operation is block device >>> +mirroring, incremental block device backup or any other operation with >>> +a concept of data

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

2016-12-02 Thread Alex Bligh
John, >> +Some storage formats and operations over such formats express a >> +concept of data dirtiness. Whether the operation is block device >> +mirroring, incremental block device backup or any other operation with >> +a concept of data dirtiness, they all share a need to provide a list >> +of

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

2016-12-02 Thread Vladimir Sementsov-Ogievskiy
02.12.2016 02:42, John Snow wrote: (B) In the case of "User just wanted to look around," the bitmap should be merged back into the bitmap it was forked from. currently existing example: "failed incremental backup" -- Best regards, Vladimir

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

2016-12-01 Thread John Snow
Hi Alex, let me try my hand at clarifying some points... On 11/29/2016 07:57 AM, Alex Bligh wrote: > Vladimir, > > I went back to April to reread the previous train of conversation > then found you had helpfully summarised some if it. Comments > below. > > Rather than comment on many of the

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

2016-11-29 Thread Vladimir Sementsov-Ogievskiy
29.11.2016 17:52, Alex Bligh wrote: Vladimir, 4. Q: Should not get_{allocated,dirty} be separate commands? cons: Two commands with almost same semantic and similar means? pros: However here is a good point of separating clearly defined and native for block devices

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

2016-11-29 Thread Alex Bligh
Vladimir, >>> 4. Q: Should not get_{allocated,dirty} be separate commands? >>> cons: Two commands with almost same semantic and similar means? >>> pros: However here is a good point of separating clearly defined and >>> native >>> for block devices GET_BLOCK_STATUS from user-driven

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

2016-11-29 Thread Vladimir Sementsov-Ogievskiy
29.11.2016 15:57, Alex Bligh wrote: Vladimir, I went back to April to reread the previous train of conversation then found you had helpfully summarised some if it. Comments below. Rather than comment on many of the points individual, the root of my confusion and to some extent

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

2016-11-29 Thread Alex Bligh
Vladimir, I went back to April to reread the previous train of conversation then found you had helpfully summarised some if it. Comments below. Rather than comment on many of the points individual, the root of my confusion and to some extent uncomfortableness about this proposal is 'who owns the

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

2016-11-25 Thread Stefan Hajnoczi
On Fri, Nov 25, 2016 at 02:28:16PM +0300, Vladimir Sementsov-Ogievskiy wrote: > With the availability of sparse storage formats, it is often needed > to query status of a particular range and read only those blocks of > data that are actually present on the block device. > > To provide such