[Nbd] The future is finally looking good for you in 2016

[Nbd] Mahindra Mojo, now in your city!

-- ___ Nbd-general mailing list

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 05:08 PM, Wouter Verhelst wrote: > On Mon, Apr 04, 2016 at 10:54:02PM +0300, Denis V. Lunev wrote: >> 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 >>

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On Mon, Apr 04, 2016 at 10:54:02PM +0300, Denis V. Lunev wrote: > 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

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 04:40 PM, Wouter Verhelst wrote: > Hi, > > Need to look into this in some detail, for which I don't have the time > (or the non-tiredness ;-) right now, but these two caught my eye: > >> +The payload is structured as a list of one or more descriptors, >> +each with this

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

Hi, Need to look into this in some detail, for which I don't have the time (or the non-tiredness ;-) right now, but these two caught my eye: On Mon, Apr 04, 2016 at 10:39:10AM -0600, Eric Blake wrote: [...] > +* `NBD_REPLY_TYPE_BLOCK_STATUS` > + > +*length* MUST be a positive integer

[Nbd] [PATCH v2] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE

qemu already has an existing server implementation option that will explicitly search the payload of NBD_CMD_WRITE for large blocks of zeroes, and punch holes in the underlying file. For old clients that don't know how to use the new NBD_CMD_WRITE_ZEROES, this is a workaround to keep the server's

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 4 Apr 2016, at 22:25, Eric Blake wrote: > On 04/04/2016 03:07 PM, Alex Bligh wrote: >> >> On 4 Apr 2016, at 21:26, Eric Blake wrote: >> >>> Huh? The current proposal _requires_ these to be separate queries. You >>> cannot query dirtiness at the same

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/05/2016 12:17 AM, Eric Blake wrote: > On 04/04/2016 03:04 PM, Denis V. Lunev wrote: >> In v1 we have had 'status' field, which can have the >> following values for dirty request: >> >> + - `NBD_STATE_DIRTY` (0x0), LBA extent is dirty; >> + - `NBD_STATE_CLEAN` (0x1), LBA extent is

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 03:07 PM, Alex Bligh wrote: > > On 4 Apr 2016, at 21:26, Eric Blake wrote: > >> Huh? The current proposal _requires_ these to be separate queries. You >> cannot query dirtiness at the same time as allocation, because the value >> of NBD_CMD_FLAG_DIRTY is

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 03:04 PM, Denis V. Lunev wrote: > In v1 we have had 'status' field, which can have the > following values for dirty request: > > + - `NBD_STATE_DIRTY` (0x0), LBA extent is dirty; > + - `NBD_STATE_CLEAN` (0x1), LBA extent is clean. > > in the extent structure: > > +

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 4 Apr 2016, at 21:34, Eric Blake wrote: > The original design abused the 16-bit 'flags' field of each command to > instead try and treat that value as a bitmap number, instead of a > bitwise-or'd set of flags. That was one of the complaints against v1, > and was fixed in

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 4 Apr 2016, at 21:26, Eric Blake wrote: > Huh? The current proposal _requires_ these to be separate queries. You > cannot query dirtiness at the same time as allocation, because the value > of NBD_CMD_FLAG_DIRTY is distinct between the two queries. OK, so you can ask for

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 11:34 PM, Eric Blake wrote: > On 04/04/2016 02:08 PM, Denis V. Lunev wrote: >>> 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

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

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 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

Re: [Nbd] [PATCH 2/2] NBD proto: add GET_LBA_STATUS extension

On 04/04/2016 02:16 PM, Denis V. Lunev wrote: >> +The following request types are currently defined for the command: >> + >> +1. Block provisioning state >> + >> +Upon receiving an `NBD_CMD_GET_LBA_STATUS` command with command flags >> +field set to `NBD_FLAG_GET_ALLOCATED` (0x0),

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 11:08 PM, Alex Bligh wrote: > On 4 Apr 2016, at 21:04, Denis V. Lunev wrote: > >>> Sure, but given you can't report dirtiness without also reporting >>> allocation, if they are are at different blocksize I'd rather they >>> were in different commands, because

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 11:15 PM, Alex Bligh wrote: > On 4 Apr 2016, at 21:13, Denis V. Lunev 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

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 01:58 PM, Alex Bligh wrote: > Eric, > >> Nothing requires the two uses to report at the same granularity. THe >> NBD_REPLY_TYPE_BLOCK_STATUS allows the server to divide into descriptors >> as it sees fit (so it could report holes at a 4k granularity, but >> dirtiness only at a 64k

Re: [Nbd] [PATCH 2/2] NBD proto: add GET_LBA_STATUS extension

On 03/23/2016 05:16 PM, Denis V. Lunev wrote: > From: Pavel Borzenkov > > With the availability of sparse storage formats, it is often needed to > query status of a particular LBA range and read only those blocks of > data that are actually present on the block device. >

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 11:03 PM, Alex Bligh wrote: > On 4 Apr 2016, at 20:54, Denis V. Lunev 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

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 4 Apr 2016, at 21:04, Denis V. Lunev wrote: >> Sure, but given you can't report dirtiness without also reporting >> allocation, if they are are at different blocksize I'd rather they >> were in different commands, because otherwise the code to report >> block size needs to

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 10:58 PM, Alex Bligh wrote: > Eric, > >> Nothing requires the two uses to report at the same granularity. THe >> NBD_REPLY_TYPE_BLOCK_STATUS allows the server to divide into descriptors >> as it sees fit (so it could report holes at a 4k granularity, but >> dirtiness only at a 64k

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 4 Apr 2016, at 20:54, Denis V. Lunev 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

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

Eric, > Nothing requires the two uses to report at the same granularity. THe > NBD_REPLY_TYPE_BLOCK_STATUS allows the server to divide into descriptors > as it sees fit (so it could report holes at a 4k granularity, but > dirtiness only at a 64k granularity) - all that matters is that when all >

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/04/2016 10:34 PM, Eric Blake wrote: > On 04/04/2016 12:06 PM, Alex Bligh wrote: >> On 4 Apr 2016, at 17:39, Eric Blake wrote: >> >>> +This command is meant to operate in tandem with other (non-NBD) >>> +channels to the server. Generally, a "dirty" block is a

Re: [Nbd] [Qemu-devel] [PATCH 2/2] NBD proto: add GET_LBA_STATUS extension

On 04/04/2016 04:18 AM, Markus Pargmann wrote: > Hi, > > back from my easter vacation. A bit surprised to find 200 mails in the > NBD mailing list ;). > >> Yes. This has been discussed on the nbd-general list in the past. There >> is also the (significant) problem of the server having maybe

Re: [Nbd] [Qemu-devel] [PATCH 2/2] NBD proto: add GET_LBA_STATUS extension

On 03/23/2016 08:16 AM, Denis V. Lunev wrote: > From: Pavel Borzenkov > > With the availability of sparse storage formats, it is often needed to > query status of a particular LBA range and read only those blocks of > data that are actually present on the block device.

Re: [Nbd] [PATCH] doc: Flip bit sense for allowing trim during WRITE_ZEROES

On 4 Apr 2016, at 14:56, Eric Blake wrote: > Question - qemu already has the notion of an nbd server that can be > configured to explicitly check for large repetitions of zero during > NBD_CMD_WRITE, and create holes in the corresponding file as a result > (basically because

Re: [Nbd] [PATCH] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE

On 4 Apr 2016, at 15:15, Eric Blake wrote: > qemu already has an existing server implementation option that will > explicitly search the payload of NBD_CMD_WRITE for large blocks of > zeroes, and punch holes in the underlying file. For old clients > that don't know how to

Re: [Nbd] [PATCH] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE

On 04/04/2016 08:47 AM, Denis V. Lunev wrote: > On 04/04/2016 05:15 PM, Eric Blake wrote: >> qemu already has an existing server implementation option that will >> explicitly search the payload of NBD_CMD_WRITE for large blocks of >> zeroes, and punch holes in the underlying file. For old clients

Re: [Nbd] [PATCH] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE

On 04/04/2016 05:15 PM, Eric Blake wrote: > qemu already has an existing server implementation option that will > explicitly search the payload of NBD_CMD_WRITE for large blocks of > zeroes, and punch holes in the underlying file. For old clients > that don't know how to use the new

[Nbd] [PATCH] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE

qemu already has an existing server implementation option that will explicitly search the payload of NBD_CMD_WRITE for large blocks of zeroes, and punch holes in the underlying file. For old clients that don't know how to use the new NBD_CMD_WRITE_ZEROES, this is a workaround to keep the server's

Re: [Nbd] [PATCH] doc: Flip bit sense for allowing trim during WRITE_ZEROES

On 04/01/2016 03:29 PM, Eric Blake wrote: > Rather than requiring allocation by default and allowing trims > only on request during WRITE_ZEROES, it seems like a better > default is to allow server optimizations by default and require > full allocation by specific request. Since WRITE_ZEROES is >

Re: [Nbd] [Qemu-devel] [PATCH 2/2] NBD proto: add GET_LBA_STATUS extension

Hi, back from my easter vacation. A bit surprised to find 200 mails in the NBD mailing list ;). On Friday 25 March 2016 09:49:29 Wouter Verhelst wrote: > On Thu, Mar 24, 2016 at 04:08:13PM -0600, Eric Blake wrote: > > On 03/23/2016 08:16 AM, Denis V. Lunev wrote: > > > From: Pavel Borzenkov

Re: [Nbd] Compiling on OS-X

On 4 Apr 2016, at 07:16, Wouter Verhelst wrote: > Note though that I said "the files must exist", not "the files must be > valid". If you want to just do a test build of the code, you can create > them with "touch" and be done with it. Yep, this plus commenting the line out in

Re: [Nbd] Compiling on OS-X

On Sun, Apr 03, 2016 at 04:31:46PM +0100, Alex Bligh wrote: > These appear to be completely different programs. I can't find the latter in > brew. They are. > So > > 1. Has anyone got this to compile with OS-X? I'm not sure. First and foremost, note that they're docbook-sgml rather than