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

> On 8 Dec 2016, at 15:59, Eric Blake wrote: > > We should use similar wording to whatever we already say about what a > client would see when reading data cleared by NBD_CMD_TRIM. After all, > the status of STATE_HOLE set and STATE_ZERO clear is what you logically > get

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

On 12/08/2016 08:40 AM, Alex Bligh wrote: >>> + metadata context is the basic "exists at all" metadata context. >>> >>> Disagree. You're saying that if a server supports metadata contexts >>> at all, it must support this one. >> >> No, I'm trying to say that this metadata context exposes whether

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

Wouter, >> +- `NBD_OPT_META_CONTEXT` (10) >> + >> +Return a list of `NBD_REP_META_CONTEXT` replies, one per context, >> +followed by an `NBD_REP_ACK`. If a server replies to such a request >> +with no error message, clients >> >> "*the* server" / "*the* cient" >> >> Perhaps only an

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

On Thu, Dec 08, 2016 at 03:39:19AM +, Alex Bligh wrote: > > > 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

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

On 12/06/2016 08:32 AM, Wouter Verhelst wrote: > Hi John > > Sorry for the late reply; weekend was busy, and so was monday. > No problems. > On Fri, Dec 02, 2016 at 03:39:08PM -0500, John Snow wrote: >> On 12/02/2016 01:45 PM, Alex Bligh wrote: >>> John, >>> > +Some storage formats and

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

Hi John Sorry for the late reply; weekend was busy, and so was monday. On Fri, Dec 02, 2016 at 03:39:08PM -0500, 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.

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

Hi Vladimir, On Thu, Dec 01, 2016 at 02:26:28PM +0300, Vladimir Sementsov-Ogievskiy wrote: > 01.12.2016 13:14, Wouter Verhelst wrote: [...] > > -- `NBD_ALLOC_ADD_CONTEXT` (2): the list of allocation contexts > > +- `NBD_META_ADD_CONTEXT` (2): the list of metadata contexts > >

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

01.12.2016 13:14, Wouter Verhelst wrote: Here's another update. Changes since previous version: - Rename "allocation context" to "metadata context" - Stop making metadata context 0 be special; instead, name it "BASE:allocation" and allow it to be selected like all other contexts. - Clarify

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

Here's another update. Changes since previous version: - Rename "allocation context" to "metadata context" - Stop making metadata context 0 be special; instead, name it "BASE:allocation" and allow it to be selected like all other contexts. - Clarify in a bit more detail when a server MAY omit

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

Hi, Wouter! > Actually, come to think of that. What is the exact use case for this thing? I > understand you're trying to create incremental backups of things, which would > imply you don't write from the client that is getting the ? > block status thingies, right? Overall, the most desired

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

On Tue, Nov 29, 2016 at 06:07:56PM +0300, Vladimir Sementsov-Ogievskiy wrote: > 29.11.2016 17:52, Alex Bligh wrote: > > Vladimir, > >> if the bitmap is 010101010101 we will have too many descriptors. > >> For example, 16tb disk, 64k granularity -> 2G of descriptors > >> payload. > > Yep. And the

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

Hi Vladimir, On Tue, Nov 29, 2016 at 03:41:10PM +0300, Vladimir Sementsov-Ogievskiy wrote: > Hi, > > 29.11.2016 13:50, Wouter Verhelst wrote: > > Hi, > > On Mon, Nov 28, 2016 at 06:33:24PM +0100, Wouter Verhelst wrote: > > However, I'm arguing that if we're going to provide

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

> On 29 Nov 2016, at 10:50, Wouter Verhelst wrote: > > +- `NBD_OPT_ALLOC_CONTEXT` (10) > + > +Return a list of `NBD_REP_ALLOC_CONTEXT` replies, one per context, > +followed by an `NBD_REP_ACK`. If a server replies to such a request > +with no error message, clients MAY

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

Hi, 29.11.2016 13:50, Wouter Verhelst wrote: Hi, On Mon, Nov 28, 2016 at 06:33:24PM +0100, Wouter Verhelst wrote: However, I'm arguing that if we're going to provide information about snapshots, we should be able to properly refer to these snapshots from within an NBD context. My previous

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

29.11.2016 13:18, Kevin Wolf wrote: Am 27.11.2016 um 20:17 hat Wouter Verhelst geschrieben: 3. Q: selecting of dirty bitmap to export A: several variants: 1: id of bitmap is in flags field of request pros: - simple cons: - it's a hack. flags field is for other

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

Hi, On Mon, Nov 28, 2016 at 06:33:24PM +0100, Wouter Verhelst wrote: > However, I'm arguing that if we're going to provide information about > snapshots, we should be able to properly refer to these snapshots from > within an NBD context. My previous mail suggested adding a negotiation > message

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

Am 27.11.2016 um 20:17 hat Wouter Verhelst geschrieben: > > 3. Q: selecting of dirty bitmap to export > >A: several variants: > > 1: id of bitmap is in flags field of request > > pros: - simple > > cons: - it's a hack. flags field is for other uses. > >

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

On Mon, Nov 28, 2016 at 06:33:24PM +0100, Wouter Verhelst wrote: > Hi Stefan, > > On Mon, Nov 28, 2016 at 11:19:44AM +, Stefan Hajnoczi wrote: > > On Sun, Nov 27, 2016 at 08:17:14PM +0100, Wouter Verhelst wrote: > > > Quickly: the reason I haven't merged this yes is twofold: > > > - I wasn't

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

Hi Wouter, Some of this mess may be partially my fault, but I have not been following the NBD extension proposals up until this point. Are you familiar with the genesis behind this idea and what we are trying to accomplish in general? We had the thought to propose an extension roughly

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

Hi Stefan, On Mon, Nov 28, 2016 at 11:19:44AM +, Stefan Hajnoczi wrote: > On Sun, Nov 27, 2016 at 08:17:14PM +0100, Wouter Verhelst wrote: > > Quickly: the reason I haven't merged this yes is twofold: > > - I wasn't thrilled with the proposal at the time. It felt a bit > > hackish, and

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

On Sun, Nov 27, 2016 at 08:17:14PM +0100, Wouter Verhelst wrote: > Quickly: the reason I haven't merged this yes is twofold: > - I wasn't thrilled with the proposal at the time. It felt a bit > hackish, and bolted onto NBD so you could use it, but without defining > everything in the NBD

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

Hi Vladimir, Quickly: the reason I haven't merged this yes is twofold: - I wasn't thrilled with the proposal at the time. It felt a bit hackish, and bolted onto NBD so you could use it, but without defining everything in the NBD protocol. "We're reading some data, but it's not about you".