From: Eric Blake <eblake@redhat.com>
To: "Denis V. Lunev" <den@openvz.org>, Alex Bligh <alex@alex.org.uk>
Cc: "nbd-general@lists.sourceforge.net"
<nbd-general@lists.sourceforge.net>,
Kevin Wolf <kwolf@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Pavel Borzenkov <pborzenkov@virtuozzo.com>,
"Stefan stefanha@redhat. com" <stefanha@redhat.com>,
Wouter Verhelst <w@uter.be>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension
Date: Mon, 4 Apr 2016 15:17:46 -0600 [thread overview]
Message-ID: <5702D9FA.20207@redhat.com> (raw)
In-Reply-To: <5702D6E2.1090901@openvz.org>
[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]
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:
>
> + * 64 bits, offset (unsigned)
> + * 32 bits, length (unsigned)
> + * 16 bits, status (unsigned)
Between v1 and v2, we dropped 64-bit offset (offset is now implied, by
adding lengths of all earlier descriptors), and widened status from 16
bits to 32 bits (so that each descriptor is now naturally 8-byte aligned
and therefore easier to make a C array).
>
> with an additional NBD_STATE_DIRTY_HOLE or (DIRTY_DEALLOCATED)
> we could report the entire state using one query. The user could be
> able to read entire state which is useful for backup at once.
>
> Your current proposal is more tricky and it was misunderstood by Alex:
>
> + * 32 bits, status flags
>
> and you describe flags as
>
> + - `NBD_STATE_HOLE` (bit 0); if set, the block represents a hole
> + - `NBD_STATE_ZERO` (bit 1), if set, the block contents read as
>
> + - `NBD_STATE_CLEAN` (bit 2); if set, the block represents a
> and opinion of Alex was that all 3 bits could be set in reply to
> NBD_CMD_BLOCK_STATUS
> with NBD_CMD_FLAG_STATUS_DIRTY set.
>
> This confused him. This confuses me too.
There's nothing that says that NBD_STATE_CLEAN can't be reassigned to
bit 0. Conversely, we may want to add a future NBD_CMD_FLAG_FOO that
lets you read allocation and dirty information in the same call, in
which case having the bits be distinct will make that easier; but where
we would also make it obvious that the server is allowed to reject that
command flag as unsupported (we already state the server can reject
NBD_CMD_FLAG_STATUS_DIRTY with EINVAL as unsupported; and that it if
does not reject a dirtiness request but cannot otherwise report
anything, then the entire region is reported as dirty).
I don't have any strong opinions on whether NBD_STATE_CLEAN should
remain bit 2 or be renumbered to bit 0, although renumbering it to bit 0
would make it painfully obvious that you cannot query allocation and
dirtiness at the same time.
>
> If allocated state is not replied to command with NBD_CMD_FLAG_STATUS_DIRTY
> then why to have different meaning of bits.
Because we still have room - no need to overlap the meaning of bits as
long as we have more bits to choose from.
--
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 --]
next prev parent reply other threads:[~2016-04-04 21:17 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 16:39 [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension Eric Blake
2016-04-04 18:06 ` [Qemu-devel] [Nbd] " Alex Bligh
2016-04-04 19:34 ` Eric Blake
2016-04-04 19:54 ` Denis V. Lunev
2016-04-04 20:03 ` Alex Bligh
2016-04-04 20:08 ` Denis V. Lunev
2016-04-04 20:34 ` Eric Blake
2016-04-04 21:06 ` Denis V. Lunev
2016-04-04 21:12 ` Alex Bligh
2016-04-05 14:15 ` Paolo Bonzini
2016-04-05 15:01 ` Alex Bligh
2016-04-05 15:23 ` Paolo Bonzini
2016-04-05 15:27 ` Alex Bligh
2016-04-05 15:31 ` Paolo Bonzini
2016-04-04 23:08 ` Wouter Verhelst
2016-04-04 23:32 ` Eric Blake
2016-04-05 7:16 ` Wouter Verhelst
2016-04-05 21:44 ` Wouter Verhelst
2016-04-05 7:13 ` Alex Bligh
2016-04-04 19:58 ` Alex Bligh
2016-04-04 20:04 ` Denis V. Lunev
2016-04-04 20:08 ` Alex Bligh
2016-04-04 20:13 ` Denis V. Lunev
2016-04-04 20:15 ` Alex Bligh
2016-04-04 20:27 ` Denis V. Lunev
2016-04-04 20:45 ` Eric Blake
2016-04-04 21:04 ` Denis V. Lunev
2016-04-04 21:12 ` Alex Bligh
2016-04-04 21:17 ` Eric Blake [this message]
2016-04-04 21:27 ` Denis V. Lunev
2016-04-04 20:26 ` Eric Blake
2016-04-04 21:07 ` Alex Bligh
2016-04-04 21:25 ` Eric Blake
2016-04-04 22:06 ` Alex Bligh
2016-04-04 20:22 ` Eric Blake
2016-04-05 13:38 ` Paolo Bonzini
2016-04-04 22:40 ` Wouter Verhelst
2016-04-04 23:03 ` Eric Blake
2016-04-05 13:41 ` Paolo Bonzini
2016-04-06 5:57 ` Denis V. Lunev
2016-04-06 14:08 ` Eric Blake
2016-04-05 4:05 ` [Qemu-devel] " Kevin Wolf
2016-04-05 13:43 ` Paolo Bonzini
2016-04-07 10:38 ` Vladimir Sementsov-Ogievskiy
2016-04-07 16:10 ` Eric Blake
2016-04-07 16:21 ` [Qemu-devel] [Nbd] " Alex Bligh
2016-04-08 11:35 ` [Qemu-devel] " Kevin Wolf
2016-04-09 9:08 ` [Qemu-devel] [Nbd] " Wouter Verhelst
2016-04-13 12:38 ` [Qemu-devel] " Pavel Borzenkov
2016-04-13 14:40 ` Eric Blake
2016-04-07 15:35 ` Pavel Borzenkov
2016-04-07 15:43 ` Paolo Bonzini
2016-04-05 8:51 ` Stefan Hajnoczi
2016-04-05 9:24 ` [Qemu-devel] [Nbd] " Markus Pargmann
2016-04-05 13:50 ` Paolo Bonzini
2016-04-11 5:58 ` Markus Pargmann
2016-04-05 14:14 ` Eric Blake
2016-04-05 20:50 ` Wouter Verhelst
2016-04-11 6:07 ` Markus Pargmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5702D9FA.20207@redhat.com \
--to=eblake@redhat.com \
--cc=alex@alex.org.uk \
--cc=den@openvz.org \
--cc=kwolf@redhat.com \
--cc=nbd-general@lists.sourceforge.net \
--cc=pbonzini@redhat.com \
--cc=pborzenkov@virtuozzo.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=w@uter.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.