Hi,
On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhelst wrote:
> Tunneling the entire protocol inside an SSL connection doesn't fix that;
> if an attacker is able to hijack your TCP connections and change flags,
> then this attacker is also able to hijack your TCP connection
On Thu, Oct 02, 2014 at 01:00:04PM +0200, Paolo Bonzini wrote:
> Il 01/10/2014 22:23, Wouter Verhelst ha scritto:
> > Hi,
> >
> > On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhelst wrote:
> >> Tunneling the entire protocol inside an SSL connection doesn'
On Thu, Oct 02, 2014 at 03:50:57PM +0200, Wouter Verhelst wrote:
> On Thu, Oct 02, 2014 at 01:00:04PM +0200, Paolo Bonzini wrote:
> > Il 01/10/2014 22:23, Wouter Verhelst ha scritto:
> > > Hi,
> > >
> > > On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhels
Hi all,
(added rjones from nbdkit fame -- hi there)
So I think the following would make sense to allow TLS in NBD.
This would extend the newstyle negotiation by adding two options (i.e.,
client requests), one server reply, and one server error as well as
extend one existing reply, in the followi
On Mon, Oct 20, 2014 at 01:51:43PM +0200, Markus Armbruster wrote:
> Stefan Hajnoczi writes:
>
> > On Mon, Oct 20, 2014 at 08:58:14AM +0100, Daniel P. Berrange wrote:
> >> On Sat, Oct 18, 2014 at 07:33:22AM +0100, Richard W.M. Jones wrote:
> >> > On Sat, Oct 18,
On Mon, Oct 20, 2014 at 01:56:43PM +0200, Florian Weimer wrote:
> I cannot comment on whether the proposed STARTTLS command is at the correct
> stage of the NBD protocol. If there is a protocol description for NBD, I
> can have a look.
To make this discussion in that regard a bit easier, I've com
On Tue, Oct 21, 2014 at 10:35:06AM +0100, Daniel P. Berrange wrote:
> On Tue, Oct 21, 2014 at 12:10:39AM +0200, Wouter Verhelst wrote:
> > On Mon, Oct 20, 2014 at 01:56:43PM +0200, Florian Weimer wrote:
> > > I cannot comment on whether the proposed STARTTLS command is at
Hi Markus,
On Tue, Oct 21, 2014 at 10:17:17AM +0200, Markus Armbruster wrote:
> Wouter Verhelst writes:
> > On Mon, Oct 20, 2014 at 01:51:43PM +0200, Markus Armbruster wrote:
[...]
> >> Furthermore, STARTTLS is vulnerable to active attacks: if you can get
> >> betw
Hi all,
I haven't seen a reply to this anymore. Do people still have comments?
I'm planning on doing a release of nbd later this weekend, and would
like to include this (not the TLS implementation yet, but at least the
spec)
Thanks,
On Tue, Oct 21, 2014 at 08:30:05PM +0200, Woute
Hi,
On Thu, Oct 30, 2014 at 10:40:56AM +, Stefan Hajnoczi wrote:
> On Sat, Oct 25, 2014 at 12:43:35PM +0200, Wouter Verhelst wrote:
> > I haven't seen a reply to this anymore. Do people still have comments?
> > I'm planning on doing a release of nbd later this weeke
[Cc: to nbd-general list added]
On Wed, Sep 03, 2014 at 05:44:17PM +0100, Stefan Hajnoczi wrote:
> Hi,
> QEMU offers both NBD client and server functionality. The NBD protocol
> runs unencrypted, which is a problem when the client and server
> communicate over an untrusted network.
>
> The parti
On Thu, Sep 04, 2014 at 04:19:17PM +0200, Benoît Canet wrote:
> The Wednesday 03 Sep 2014 à 17:44:17 (+0100), Stefan Hajnoczi wrote :
> > Hi,
> > QEMU offers both NBD client and server functionality. The NBD protocol
> > runs unencrypted, which is a problem when the client and server
> > communica
On Fri, Sep 05, 2014 at 12:54:45AM +0200, Benoît Canet wrote:
> The Friday 05 Sep 2014 à 00:07:04 (+0200), Wouter Verhelst wrote :
> > On Thu, Sep 04, 2014 at 04:19:17PM +0200, Benoît Canet wrote:
> > > Prenegociating TLS look like we will accidentaly introduce some security
On Fri, Sep 05, 2014 at 09:46:18AM +0100, Hani Benhabiles wrote:
> On Wed, Sep 03, 2014 at 05:44:17PM +0100, Stefan Hajnoczi wrote:
> > Hi,
> > QEMU offers both NBD client and server functionality. The NBD protocol
> > runs unencrypted, which is a problem when the client and server
> > communicate
On Fri, Sep 05, 2014 at 09:13:26AM +0100, Daniel P. Berrange wrote:
> On Fri, Sep 05, 2014 at 12:02:18AM +0200, Wouter Verhelst wrote:
> > [Cc: to nbd-general list added]
> >
> > On Wed, Sep 03, 2014 at 05:44:17PM +0100, Stefan Hajnoczi wrote:
> > > Hi,
> &g
[nbd-general added to Cc]
Hi Daniel,
On Fri, Nov 27, 2015 at 12:20:38PM +, Daniel P. Berrange wrote:
> This series of patches implements support for TLS in the QEMU NBD
> server and client code.
>
> It is implementing the NBD_OPT_STARTTLS option that was previously
> discussed here:
>
> h
Minor nitpick:
On Fri, Nov 27, 2015 at 12:20:50PM +, Daniel P. Berrange wrote:
[...]
> @@ -563,6 +659,14 @@ static int nbd_receive_options(NBDClient *client)
> case NBD_OPT_EXPORT_NAME:
> return nbd_handle_export_name(client, length);
>
> +case NBD_O
Hi Daniel,
Something occurred to me earlier today:
On Fri, Nov 27, 2015 at 12:20:38PM +, Daniel P. Berrange wrote:
> As is, if the client connects to a TLS enabled NBD server and then
> immediately sends NBD_OPT_EXPORT_NAME, it is not possible for us
> to send back NBD_REP_ERR_TLS_REQD as the
On Wed, Dec 02, 2015 at 01:37:08PM +, Daniel P. Berrange wrote:
> On Wed, Dec 02, 2015 at 01:56:30PM +0100, Wouter Verhelst wrote:
> > Hi Daniel,
> >
> > Something occurred to me earlier today:
> >
> > On Fri, Nov 27, 2015 at 12:20:38PM +, Daniel P. Be
Hi all,
On Fri, Nov 27, 2015 at 03:06:51PM +0100, Wouter Verhelst wrote:
> I have been thinking of adding a message NBD_OPT_SELECT_EXPORT to
> replace NBD_OPT_EXPORT_NAME, which would select an export but not end
> negotiation. That would also require another message to end negotiation
&
On 20-09-13 20:00, Mark Trumpold wrote:
> Stefan,
>
> So, I tried the following:
>
> -> qemu-nbd -p 2000 /root/qemu/q1.img &
> -> nbd-client localhost 2000 /dev/nbd0 &
That won't work. nbd-client will only try the reconnect thing if you use
the "-persist" option.
Also, nbd-client will do a
On 25-09-13 16:42, Mark Trumpold wrote:
> Hello Wouter,
>
> Thank you for your input.
>
> I replayed the test as follows:
>
> -> qemu-nbd -p 2000 -persist /root/qemu/q1.img &
> -> nbd-client localhost 2000 /dev/nbd0
No.
nbd-client -persist localhost 2000 /dev/nbd0
--
This end should poin
Hi folks,
(sorry about the lateness of this reply, was busy for the last few weeks)
On Thu, Feb 18, 2016 at 11:34:04AM +0300, Denis V. Lunev wrote:
> On 02/18/2016 11:09 AM, Alex Bligh wrote:
> > On 17 Feb 2016, at 18:10, Denis V. Lunev wrote:
> >
> >> Currently available NBD_CMD_TRIM command ca
Hi all,
On Fri, Mar 04, 2016 at 03:03:26PM +0100, Paolo Bonzini wrote:
> NBD-wise, I think the TRIM command is good as it is, and
> NBD_CMD_WRITE_ZEROES should be added like Den is doing.
>
> It also makes sense to use trimming to implement NBD_CMD_WRITE_ZEROES,
> but it should be explicitly requ
On Tue, Mar 29, 2016 at 09:12:02AM -0600, Eric Blake wrote:
> On 03/29/2016 08:37 AM, Alex Bligh wrote:
> > Eric,
> >
> >> I guess what I need to add is that in transmission phase, most commands
> >> have exactly one response per request; but commands may document
> >> scenarios where there will b
Hi Eric,
Having read this in more detail now:
On Mon, Mar 28, 2016 at 09:56:36PM -0600, Eric Blake wrote:
> + The server MUST ensure that each read chunk lies within the original
> + offset and length of the original client request, MUST NOT send read
> + chunks that would cover the same offse
On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote:
> On 03/29/2016 11:34 AM, Alex Bligh wrote:
> > I would agree. I think if it supports the structured reply semantics,
> > it should also support 'DF'. So if you know the server supports
> > structured replies, you know you can set DF on th
On Tue, Mar 29, 2016 at 12:07:59PM -0600, Eric Blake wrote:
> On 03/29/2016 12:03 PM, Wouter Verhelst wrote:
> > On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote:
> >> Supporting DF merely transfers the burden of collection between server
> >> and client. I s
On Tue, Mar 29, 2016 at 12:23:31PM -0600, Eric Blake wrote:
> On 03/29/2016 11:53 AM, Wouter Verhelst wrote:
> > Hi Eric,
> >
> > Having read this in more detail now:
> >
> > On Mon, Mar 28, 2016 at 09:56:36PM -0600, Eric Blake wrote:
> >> + The se
On Tue, Mar 29, 2016 at 08:51:57PM +0200, Wouter Verhelst wrote:
> On Tue, Mar 29, 2016 at 12:23:31PM -0600, Eric Blake wrote:
> > Unfortunately, I chose the design of 0 or more structured replies
> > followed by a normal reply, so that the normal reply is a reliable
> > indic
On Tue, Mar 29, 2016 at 09:39:43PM +0100, Alex Bligh wrote:
> Here's a strawman for the structured reply section. I haven't
> covered negotation.
LGTM, for the most part.
[...]
> +Each chunk consists of the following:
> +
> +S: 32 bits, 0x668e33ef, magic (`NBD_STRUCTURED_REPLY_MAGIC`)
> +S: 32 bi
Hi Alex,
On Tue, Mar 29, 2016 at 09:44:39PM +0100, Alex Bligh wrote:
> Eric,
> > For all remaining existing commands, that is just more overhead on the
> > wire. The existing non-structured replies do not send any data; they
> > are 16 bytes each (only NBD_CMD_READ sends more than 16 bytes in one
On Tue, Mar 29, 2016 at 10:59:18PM +0100, Alex Bligh wrote:
> On 29 Mar 2016, at 21:57, Wouter Verhelst wrote:
> >
> > I understand why you do it this way (we don't need 2^16 reply types),
> > but (in contrast to the flags in the request packet) this makes it
>
On Tue, Mar 29, 2016 at 11:05:38PM +0100, Alex Bligh wrote:
>
> On 29 Mar 2016, at 22:05, Wouter Verhelst wrote:
>
> >>> For all remaining existing commands, that is just more overhead on the
> >>> wire. The existing non-structured replies do not send any d
Hi Eric,
On Tue, Mar 29, 2016 at 05:00:57PM -0600, Eric Blake wrote:
> I wrote this in parallel with Alex's strawman proposals, so I
> may have picked up on some of his ideas, while diverging in
> other places.
>
> Changes since v1: rebase, resend some pre-req patches, switch
> from global/client
Morning,
On Wed, Mar 30, 2016 at 07:59:15AM +0100, Alex Bligh wrote:
> On 30 Mar 2016, at 00:17, Eric Blake wrote:
> >>
> >> -The server replies with:
> >> +Replies take one of two forms. They may either be structured replies,
> >
> > Hmm, you put your strawman directly in the 'transmission pha
Hi all,
(side note: this seems to be mostly an NBD discussion at this point.
Does qemu-devel need to be in the loop before we've finished that? I
don't care either way, but then I don't want to bore or annoy people...)
On Wed, Mar 30, 2016 at 11:45:04AM -0600, Eric Blake wrote:
> On 03/30/2016 12
On Wed, Mar 30, 2016 at 12:43:57PM -0600, Eric Blake wrote:
> On 03/30/2016 01:33 AM, Wouter Verhelst wrote:
> > Morning,
> >
> > On Wed, Mar 30, 2016 at 07:59:15AM +0100, Alex Bligh wrote:
> >> On 30 Mar 2016, at 00:17, Eric Blake wrote:
> >>>>
>
So,
On Tue, Mar 29, 2016 at 05:01:00PM -0600, Eric Blake wrote:
[...]
> +- `NBD_OPT_STRUCTURED_READ` (8)
> +
> +Defined by the experimental `Structured Read` extension; see below.
(detail: that makes the "structured read" extension be typographically
different from everything else. Either mak
On Wed, Mar 30, 2016 at 02:54:41PM -0600, Eric Blake wrote:
> On 03/30/2016 01:51 PM, Wouter Verhelst wrote:
>
> > (side note: this seems to be mostly an NBD discussion at this point.
> > Does qemu-devel need to be in the loop before we've finished that? I
> > don&
On Thu, Mar 31, 2016 at 02:34:24PM -0600, Eric Blake wrote:
> On 03/31/2016 02:17 PM, Alex Bligh wrote:
> >> even if we aren't quite sure
> >> what to document of those flags. And that means qemu is correct, and
> >> the NBD protocol has a bug. Since you contributed the FUA flag, is that
> >> som
On Thu, Mar 31, 2016 at 07:15:32PM +0100, Alex Bligh wrote:
> NBD_CMD_FLAG_FUA is defined as 1<<0 in the documentation, but
> 1<<16 in nbd.h. It is not used anywhere within the code.
Yes it is:
wouter@gangtai:~/code/c/nbd$ grep -rl CMD_FLAG_FUA *
doc/proto.md
make-integrityhuge.c
nbd.h
nbd-server
On Fri, Apr 01, 2016 at 12:03:19AM +0100, Alex Bligh wrote:
> Improve the documentation of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA. Specifically
> the latter may be set on any command, and its semantics on commands other
> than NBD_CMD_WRITE need explaining. Further, explain how these relate to
> reorde
Thanks, applied.
On Fri, Apr 01, 2016 at 12:16:48AM +0100, Alex Bligh wrote:
> Clarify that
>
> * The name is not NUL terminated (not just that the length
> 'does not include NUL termination' which might be taken to mean
> there is NUL termination but the length doesn't include it.
>
> * The
adds WRITE_ZEROES extension with one new
> NBD_CMD_WRITE_ZEROES command.
>
> Signed-off-by: Pavel Borzenkov
> Signed-off-by: Denis V. Lunev
> CC: Wouter Verhelst
> CC: Paolo Bonzini
> CC: Kevin Wolf
> CC: Stefan Hajnoczi
> CC: Wouter Verhelst
> CC:
On Fri, Apr 01, 2016 at 10:32:50AM +0100, Alex Bligh wrote:
> #define NBD_CMD_MASK_COMMAND 0x
> -#define NBD_CMD_FLAG_FUA (1<<16)
> +#define NBD_CMD_SHIFT (16)
> +#define NBD_CMD_FLAG_FUA ((1 << 0) << NBD_CMD_SHIFT)
That works too, I suppose.
However, like I said, I need to clean this up
On Fri, Apr 01, 2016 at 10:28:03AM +0100, Alex Bligh wrote:
>
> On 1 Apr 2016, at 09:35, Wouter Verhelst wrote:
>
> >> +* All write commands (that includes both `NBD_CMD_WRITE` and
> >> + `NBD_CMD_TRIM`) that the server completes (i.e. replies to)
>
On Fri, Apr 01, 2016 at 11:17:29AM +0100, Alex Bligh wrote:
> On 1 Apr 2016, at 11:10, Wouter Verhelst wrote:
> > On Fri, Apr 01, 2016 at 10:28:03AM +0100, Alex Bligh wrote:
> >> On 1 Apr 2016, at 09:35, Wouter Verhelst wrote:
> >>>> +* All write commands (that
On Fri, Apr 01, 2016 at 10:54:42AM +0100, Alex Bligh wrote:
> Improve the documentation of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA. Specifically
> the latter may be set on any command, and its semantics on commands other
> than NBD_CMD_WRITE need explaining. Further, explain how these relate to
> reorde
On Mon, Apr 04, 2016 at 12:18:37PM +0200, Markus Pargmann wrote:
> Hi,
>
> back from my easter vacation. A bit surprised to find 200 mails in the
> NBD mailing list ;).
I'm sure you were :-)
[...]
> > Yes. This has been discussed on the nbd-general list in the past. There
> > is also the (signif
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 multiple
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 publish
On Mon, Apr 04, 2016 at 05:32:34PM -0600, Eric Blake wrote:
> 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
On Tue, Apr 05, 2016 at 10:43:14AM -0600, Eric Blake wrote:
> On 04/05/2016 03:38 AM, Markus Pargmann wrote:
> > Hi,
> >
> > On Monday 04 April 2016 16:15:43 Eric Blake wrote:
> >> qemu already has an existing server implementation option that will
> >> explicitly search the payload of NBD_CMD_WRI
On Tue, Apr 05, 2016 at 08:14:01AM -0600, Eric Blake wrote:
> On 04/05/2016 03:24 AM, Markus Pargmann wrote:
>
> >> +requested.
> >> +
> >> +The client SHOULD NOT read from an area that has both
> >> +`NBD_STATE_HOLE` set and `NBD_STATE_ZERO` clear.
> >
> > Why not? If we don't ex
On Tue, Apr 05, 2016 at 05:43:14PM +0100, Alex Bligh wrote:
> Improve the documentation of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA. Specifically
> the latter may be set on any command, and its semantics on commands other
> than NBD_CMD_WRITE need explaining. Further, explain how these relate to
> reorde
On Tue, Apr 05, 2016 at 09:42:26PM +0100, Alex Bligh wrote:
> Amend the NBD_OPT_SELECT and NBD_OPT_GO documentation as
> follows:
>
> * Change NBD_OPT_SELECT to be called NBD_OPT_INFO
>
> * Remove the 'selection' aspect of that command, so that
> it now merely returns information. This is to av
On Mon, Apr 04, 2016 at 05:32:34PM -0600, Eric Blake wrote:
> 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
On Thu, Apr 07, 2016 at 10:10:58AM -0600, Eric Blake wrote:
> On 04/07/2016 04:38 AM, Vladimir Sementsov-Ogievskiy wrote:
> > On 05.04.2016 16:43, Paolo Bonzini wrote:
> >>
> >> On 05/04/2016 06:05, Kevin Wolf wrote:
> >>> The options I can think of is adding a request field "max number of
> >>> de
On Thu, Apr 07, 2016 at 12:35:59PM +0100, Alex Bligh wrote:
> * Call out TLS into a separate section
>
> * Add details of the TLS protocol itself
>
> * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can
> be initiated from either side (as required by the TLS standard I be
On Thu, Apr 07, 2016 at 02:56:48PM +0100, Daniel P. Berrange wrote:
> I don't really agree that there's a use case of mixing
> tls & non-tls exports in the same server.
There is: swap-on-NBD and TLS do not mix.
Without special handling, swapping to the network is prone to deadlocks,
because the m
On Thu, Apr 07, 2016 at 08:31:23AM -0600, Eric Blake wrote:
> > +The FORCEDTLS mode of operation has an implementation problem in
> > +that the client MAY legally simply send a `NBD_OPT_EXPORT_NAME`
> > +to enter transmission mode without previously sending any options.
> > +Therefore, if a server
On Thu, Apr 07, 2016 at 07:32:47PM +0100, Alex Bligh wrote:
[...]
> +### Server-side requirements
> +
> +There are four modes of operation for a server. The
> +server MUST support one of these modes.
> +
> +* The server operates entirely without TLS ('NOTLS'); OR
> +
> +* The server makes TLS avail
On Fri, Apr 08, 2016 at 04:05:40PM -0600, Eric Blake wrote:
> This series is for qemu 2.7, and will probably need some rework
> especially since some of it is trying to implement features
> that are still marked experimental in upstream NBD.
>
> Included are some interoperability bug fixes, code c
On Sat, Apr 09, 2016 at 11:05:16AM +0100, Alex Bligh wrote:
>
> On 9 Apr 2016, at 10:50, Wouter Verhelst wrote:
>
> > So if I want to swap to qemu-nbd, I cannot also have encrypted
> > connections to the same server. Got it.
>
> AFAIK qemu-nbd only supports a
On Sat, Apr 09, 2016 at 11:04:09AM +0100, Alex Bligh wrote:
[...]
> > [...]
> >> +The server MUST NOT send `NBD_REP_ERR_TLS_REQD` in reply to
> >> +any command if TLS has already been neogitated. The server
> >
> > negotiated
>
> I'd make sure you're looking at the latest version as Eagle Eyed Er
On Sat, Apr 09, 2016 at 11:26:23AM +0100, Alex Bligh wrote:
>
> On 9 Apr 2016, at 11:11, Wouter Verhelst wrote:
> > Since you say zero here, how is it different from OPTIONALTLS?
> >
> > If "not at all", just drop optional.
>
> As per previous message, b
On Sat, Apr 09, 2016 at 12:21:03PM +0100, Alex Bligh wrote:
> An alternative route would be to delete OPTIONALTLS, and make some of
> the MUST requirements in SELECTIVETLS say "MUST xyz unless there are
> no TLS-only exports". However, this makes it rather harder to read,
> so I described that case
Mostly there. Final note:
On Sun, Apr 10, 2016 at 01:47:32PM +0100, Alex Bligh wrote:
> diff --git a/doc/proto.md b/doc/proto.md
> index f117394..5005552 100644
> --- a/doc/proto.md
> +++ b/doc/proto.md
> @@ -195,6 +195,13 @@ request before sending the next one of the same type.
> The server MAY
On Mon, Apr 11, 2016 at 09:34:44PM +0100, Alex Bligh wrote:
> Eric,
>
> On 11 Apr 2016, at 21:14, Eric Blake wrote:
> > Current qemu NBD server implementation does NOT send a reply to
> > NBD_OPT_ABORT, but immediately closes the connection. I don't know if
> > that is a bug in qemu (especially g
On Tue, Apr 12, 2016 at 08:47:49AM +0100, Alex Bligh wrote:
>
> On 12 Apr 2016, at 07:01, Wouter Verhelst wrote:
>
> > hat doesn't mean OPT_ABORT not having a reply is necessarily a good
> > idea. Since it's only used by reference nbd-client in just one use case
&
On Tue, Apr 12, 2016 at 10:53:57AM +0100, Alex Bligh wrote:
> Wouter,
>
> On 12 Apr 2016, at 10:20, Wouter Verhelst wrote:
>
> > To summarize, there are three ways for the connection to end:
> >
> > - The client wishes to end the session, and sends the approp
On Tue, Apr 12, 2016 at 01:57:25PM +0100, Alex Bligh wrote:
>
> On 12 Apr 2016, at 13:40, Wouter Verhelst wrote:
>
> > Right, that sounds good.
>
> Great. I may look at that when the other doc patches are applied.
>
> On which note, back to $subject, how is PATCH
Hi Eric,
On Wed, Apr 20, 2016 at 09:42:02AM -0600, Eric Blake wrote:
[...]
> But in 3.9, the overlap bug was still present, and the set of global
> flags had grown to include NBD_FLAG_NO_ZEROS (commit 038e066), which
> overlaps with NBD_FLAG_READ_ONLY. Ouch. This means that a client
> talking to
WRITE_ZEROES extension with one new
> NBD_CMD_WRITE_ZEROES command.
>
> Signed-off-by: Pavel Borzenkov
> Reviewed-by: Roman Kagan
> Signed-off-by: Denis V. Lunev
> CC: Wouter Verhelst
> CC: Paolo Bonzini
> CC: Kevin Wolf
> CC: Stefan Hajnoczi
> ---
> doc/proto.md |
On Wed, Mar 23, 2016 at 09:14:10AM -0600, Eric Blake wrote:
> On 03/23/2016 08:16 AM, Denis V. Lunev wrote:
[...]
> [1] Oh, you ARE adding this to the "Experimental extensions" section of
> the document, so your wording IS correct. I guess the idea is that we
> write up the documentation in the ex
onse of NBD_CMD_GET_LBA_STATUS command, instead of a
> bitmap.
>
> Signed-off-by: Pavel Borzenkov
> Reviewed-by: Roman Kagan
> Signed-off-by: Denis V. Lunev
> CC: Wouter Verhelst
> CC: Paolo Bonzini
> CC: Kevin Wolf
> CC: Stefan Hajnoczi
> ---
> doc/proto
On Thu, Mar 24, 2016 at 10:16:19AM +0300, Pavel Borzenkov wrote:
> So if no one objects, I'll send a patch correcting current spec
> ambiguities and than patches with new proposed commands.
Yes please. Thank you.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
On Thu, Mar 24, 2016 at 10:57:06AM +0300, Pavel Borzenkov wrote:
> On Wed, Mar 23, 2016 at 06:21:16PM +0100, Wouter Verhelst wrote:
> > So, the semantics of your proposed WRITE_ZEROES are exactly the same as
> > the WRITE command, except that no payload is sent?
> >
> >
On Thu, Mar 24, 2016 at 11:25:52AM +0300, Pavel Borzenkov wrote:
> On Wed, Mar 23, 2016 at 07:14:54PM +0100, Kevin Wolf wrote:
> > Am 23.03.2016 um 18:58 hat Wouter Verhelst geschrieben:
> > > On Wed, Mar 23, 2016 at 05:16:02PM +0300, Denis V. Lunev wrote:
> > > >
On Thu, Mar 24, 2016 at 11:43:18AM +0300, Pavel Borzenkov wrote:
> On Wed, Mar 23, 2016 at 06:58:34PM +0100, Wouter Verhelst wrote:
> > On Wed, Mar 23, 2016 at 05:16:02PM +0300, Denis V. Lunev wrote:
> > > +2. Block dirtiness state
> > > +
> > > +Upon
Hi Paolo,
On Thu, Mar 24, 2016 at 12:55:51PM +0100, Paolo Bonzini wrote:
>
>
> On 23/03/2016 18:58, Wouter Verhelst wrote:
> >> +To provide such class of information, `GET_LBA_STATUS` extension adds new
> >> +`NBD_CMD_GET_LBA_STATUS` command which returns a list of
On Thu, Mar 24, 2016 at 02:36:52PM +0300, Pavel Borzenkov wrote:
> On Thu, Mar 24, 2016 at 09:41:29AM +0100, Wouter Verhelst wrote:
> > Okay, that alleviates my concerns.
> >
> > In that case it might be useful if the server could say something along
> > the lines of &q
On Thu, Mar 24, 2016 at 12:37:33PM +0100, Paolo Bonzini wrote:
>
>
> On 24/03/2016 09:26, Wouter Verhelst wrote:
> >> >
> >> > No, there is no specific reason. Looks like NBD_CMD_FLAG_ZEROES fits the
> >> > spec and implementations nicely. So I
On Thu, Mar 24, 2016 at 04:33:42PM +0100, Paolo Bonzini wrote:
> On 24/03/2016 16:25, Eric Blake wrote:
> >> However, let's make these bits, so that
> >>
> >> NBD_STATE_ALLOCATED (0x1), LBA extent is present on the block device
> >> NBD_STATE_ZERO (0x2), LBA extent will read as zeroes
> >
> > Shou
On Thu, Mar 24, 2016 at 05:07:47PM +0100, Kevin Wolf wrote:
> Am 24.03.2016 um 17:04 hat Eric Blake geschrieben:
> > On 03/24/2016 09:53 AM, Wouter Verhelst wrote:
> > > On Thu, Mar 24, 2016 at 04:33:42PM +0100, Paolo Bonzini wrote:
> > >> On 24/03/2016 16:25, Eric
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
> >
> > 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 th
On Mon, Mar 28, 2016 at 07:59:15AM -0600, Eric Blake wrote:
> Although the proper use of the handle field during transmission
> phase was implied, it never hurts to make it more explicit that
> clients should alter the handle on each message, and the server
> repeat the handle unchanged, in order f
egotiated with the server. State
> > explicitly that the client MUST NOT send such command without prior
> > successful negotiation.
> >
> > Signed-off-by: Pavel Borzenkov
> > Reviewed-by: Roman Kagan
> > Signed-off-by: Denis V. Lunev
> > CC: Wouter Verhe
Hi Eric,
After applying some of the other outstanding patches, this one doesn't apply
anymore. Can you rebase?
On Mon, Mar 28, 2016 at 09:56:36PM -0600, Eric Blake wrote:
> The existing transmission phase protocol is difficult to sniff,
> because correct interpretation of the server stream requir
t; >
> > Signed-off-by: Pavel Borzenkov
> > Reviewed-by: Roman Kagan
> > Signed-off-by: Denis V. Lunev
> > CC: Wouter Verhelst
> > CC: Eric Blake
> > CC: Alex Bligh
> > ---
> > doc/proto.md | 10 ++
> > 1 file changed, 10 insertions
On Tue, Mar 29, 2016 at 11:38:35AM +0200, Kevin Wolf wrote:
> Am 24.03.2016 um 17:47 hat Wouter Verhelst geschrieben:
> > On Thu, Mar 24, 2016 at 05:07:47PM +0100, Kevin Wolf wrote:
> > > Am 24.03.2016 um 17:04 hat Eric Blake geschrieben:
> > > > On 03/24/2016 0
On Mon, Jun 13, 2016 at 10:41:05PM +0100, Alex Bligh wrote:
> For amusement value, the non-threaded handler (which is not used
> any more) does not send any payload on an error:
> https://github.com/yoe/nbd/blob/master/nbd-server.c#L1734
nbd-server used to just drop the connection on read error.
On Tue, Jun 14, 2016 at 04:02:15PM +0100, Alex Bligh wrote:
>
> On 14 Jun 2016, at 14:32, Paolo Bonzini wrote:
>
> >
> > On 13/06/2016 23:41, Alex Bligh wrote:
> >> That's one of the reasons that there is a proposal to add
> >> STRUCTURED_READ to the spec (although I still haven't had time to
>
On Wed, Jun 15, 2016 at 09:05:22AM +0200, Wouter Verhelst wrote:
> There are more clients than the Linux and qemu ones, but I think it's
> fair to say that those two are the most important ones. If they agree
> that a read reply which errors should come without payload, then I thi
On Wed, Jun 15, 2016 at 11:27:21AM +0100, Alex Bligh wrote:
> Perhaps this should read "If an error occurs, the server MUST either initiate
> a hard disconnect before the entire payload has been sent or
> set the appropriate code in the error field and send the response header
> without any payload
On Tue, May 10, 2016 at 04:08:50PM +0100, Alex Bligh wrote:
> What surprises me is that a release kernel is using experimental
> NBD extensions; there's no guarantee these won't change. Or does
> fstrim work some other way?
What makes you say NBD_CMD_TRIM is experimental? It's been implemented for
On Tue, May 10, 2016 at 09:29:23AM -0600, Eric Blake wrote:
> On 05/10/2016 09:08 AM, Alex Bligh wrote:
> > Eric,
> >
> >> Hmm. The current wording of the experimental block size additions does
> >> NOT allow the client to send a NBD_CMD_TRIM with a size larger than the
> >> maximum NBD_CMD_WRITE:
On Tue, May 10, 2016 at 04:38:29PM +0100, Alex Bligh wrote:
> On 10 May 2016, at 16:29, Eric Blake wrote:
> > So the kernel is currently one of the clients that does NOT honor block
> > sizes, and as such, servers should be prepared for ANY size up to
> > UINT_MAX (other than DoS handling).
>
> O
On Tue, May 17, 2016 at 10:50:01AM -0600, Eric Blake wrote:
> Option 2: An alternative solution would be to allow nbdkit to fail
> NBD_OPT_LIST with NBD_REP_ERR_UNSUP, at which point qemu client of 2.6
> should just ignore the failure and proceed on to NBD_OPT_EXPORT_NAME.
> It is the fact that it
1 - 100 of 166 matches
Mail list logo
