h you can tell), sending flush on
all channels is the only safe thing to do, without substantial protocol
changes (which I'm not sure how one would do given flush is in a sense
a synchronisation point). I think it's thus imperative this gets fixed
before the change gets merged.
--
Alex Bl
me platforms and fling systems.
What I'm therefore asking for is either:
a) that the server can say 'if you are multichannel, you will need to send
flush on each channel' (best); OR
b) that the server can say 'don't go multichannel'
as part of the negotiation stage. Of cour
even with the reference server, this patch is unsafe, and it needs adapting to
send flushes on all channels - yes it might theoretically be possible to
introduce IPC to the current server, but you'd still need some way of tying
together channels from a single client.
--
Alex Bligh
--
can sort out all the negotiation
of whether it's safe or unsafe within userspace and not bother Josef
about it? I suppose that's fine in that we can at least shorten
the CC: line, but I still think it would be helpful if the protocol
>> Now, in the reference server, NBD_CMD_FLUSH i
Wouter,
> On 6 Oct 2016, at 10:04, Wouter Verhelst wrote:
>
> Hi Alex,
>
> On Tue, Oct 04, 2016 at 10:35:03AM +0100, Alex Bligh wrote:
>> Wouter,
>>> I see now that it should be closer
>>> to the former; a more useful definition is probably
NBD should work in the face of multiple channels with
> a sane/regular backend.
On which note, I am still not convinced that fsync() provides such
semantics on all operating systems and on Linux on non-block devices.
I'm not sure all those backends are 'insane'!
out commands stuck in the
TCP queue client side, but it might be just as easy to fix that there.
I'm guessing that you're looking for something cleaner involving
some slightly more complicated signalling?
--
Alex Bligh
--
ike NFS-over-TCP reconnects. We
still might need some protocol changes (though I'm
not 100% convinced) - e.g. to say 'server restarting' -
but even if so, I can't help but think it would have
wider applica
ee to nick the entirety of the configuration section
from here: https://github.com/abligh/gonbdserver
3. You don't seem to permit validating client certificates. This
is (a) pretty easy, and (b) pretty important.
--
Alex Bligh
--
o provide a certificate chain of intermediate
certificates (and these normally go in through a different parameter
or with the public key as you need to supply more than one).
--
Alex Bligh
--
Check out the v
oblem at the present, it might help client implementations to be aware
> of it. Then again, most client implementors read this list, so
> documenting it in the protocol may be overkill.
I think the answer there is 'fix the server' rather than work
around it in the client.
--
Alex Bl
lls on old versions.
My branch is at:
https://github.com/abligh/nbd/tree/add-tls-support
if you want to nick the TLS code (including autotools etc support)
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
this codebase that doesn't butcher existing style? And if so,
> can we add it within a .dir-locals.el file to make it apply to fresh git
> checkouts?
>
From memory you want to set the 'linux' C mode.
--
Alex Bligh
signature.asc
Description:
TARTTLS, splice), and a few bug
> fixes.
>
> I think it's time to release.
TLS bits aside, I agree, though
https://github.com/NetworkBlockDevice/nbd/issues/35
is a bit annoying.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
> On 9 Nov 2016, at 10:02, Alex Bligh wrote:
>
> I have one bug filed against my proxy code (obscure error
> handling issue) I have been procrastinating looking at. I will
> copy that over if it needs fixing.
OK I fixed that one and pushed it.
I couldn't actually t
ot link to it.
Compilation fails.
There must be something wrong with the GnuTLS detection logic for old
versions, as it should either compile and link with it, or do neither.
Any chance you could take a look at that one?
--
Alex Bligh
signature.asc
Description: Message s
published in RFCs, then you are
> concerned about some advanced attacks and will wish to do this; if you do not
> regenerate then you might as well stick to the standard primes.
--
Alex Bligh
--
Developer
mail) and that needs
fixing. I suggest you could test by making it check
for version 9.9.9 and above or similar and seeing
if you get the link problem.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP
ely (for those on Raspberry Pis or similar)
--
Alex Bligh
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE
d problem / thinko, rather than an nbd client
thinko.
I suppose it would be possible to specify some sort of external command
that could be run when (re)mounting, or (if run under systemd) send it
some f
er from the server refusing to provide information? We don't
permit short reads etc.
> . The server SHOULD use different
> +*status* values between consecutive descriptors, and SHOULD use
&
ow a hole) might need backing up).
So don't we need multiple independent lists of extents? Of course a server
might *implement* them under the hood with separate bitmaps or one big
bitmap, or no bitmap at all (for instance using file extents on POSIX).
--
Alex Bligh
-
16TB disk, as it might be very large! Even if the client
worked at e.g. a 64MB level (where they'd get a maximum of 1024 extents per
reply), this isn't go
at all (well, that's my excuse
anyway).
> Anyway, I hope I am being useful and just not more confounding. It seems
> to me that we're having difficulty conveying precisely what it is we're
> trying
I tried to pick some QEMU-like ones, but I am sure there are
examples that would work outside of QEMU.
--
Alex Bligh
--
Check out the vibrant tech community on one of the world's most
engagin
s Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> __
ssue passing complete
zero status back to the client if it's so obvious from a stat().
--
Alex Bligh
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer pl
> On 6 Dec 2016, at 08:46, Alex Bligh wrote:
>
> I would support this.
>
> In fact the patch is sufficiently simple I think I'd merge this
> into extension-write-zeroes then merge that into master.
Hence:
Reviewed-By: Alex
> 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, did a &#
too and a lot of uppercase will come to the code =(
I agree
--
Alex Bligh
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Pa
uld read as
> all-zeroes) is not an invalid thing for a server to set. The spec here
> clarifies what a client should do with that information if it gets it
> (i.e., "don't read it, it doesn't contain anything interesting").
That's fair enough until the last bit in bracket
t when TRIM cannot guarantee reads-as-zero.
Yes. It was actually exactly that discussion I was trying to remember.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Developer Access Prog
d, where space is
> at a premium.
I did suggest a few non-Qemu uses (see below). I think it might be
an idea if the reference implementation supported it before
merging (which per below should be trivial).
--
Alex Bligh
> Begin forwarded message:
>
> From: Alex Bligh
&g
> +status of 0 for any block, although the server SHOULD return
> +additional status values when they can be easily detected.
> +
> +If an error occurs, the server SHOULD set the appropriate error
> +code in the error field of an error chunk. However, if the error
>
l
> + namespaces by simple request to the mailinglist.
Surely also we need to specify multiple queries?
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Check out
think the easy way to do this would be to have context IDs as a payload
to the command, like they are with NBD_CMD_WRITE, but the payload
is currently always defined to be of the length specified within the
length section.
The question really is whether we should fix this silly protocol limit
t it does not affect that?
How about:
"If a server supports the `base:allocation` metadata context, then writing
to an extent which has `NBD_STATE_HOLE` clear MUST NOT fail with ENOSPC
unless for reasons specified in the definition of another context."
>>> +For the `bas
till not be an
> error for the server to return ENOSPC)
All of this suggests 'SHOULD NOT' would be more appropriate than
'MUST NOT'.
--
Alex Bligh
--
Check out the vibrant tech community o
ed to zero
length query) list all contexts, as absence of any query is now simple.
* Move definition of namespaces in the document to somewhere more appopriate.
* Various other minor changes as discussed on the mailing list
Signed-off-by: Alex Bligh
---
doc/proto.md
ich might (in theory) return a list of blocks which are newer than
the given timestamp. It would clearly be impossible to return all such
contexts. I wonder if we should carve out an exception here.
--
Alex Bligh
-
sal) is actually fine.
#1 seems too heavy
#2 also seems pretty heavyweight - adding a whole new info command for one
bit
#3 is pretty simple, but carries the disadvantage that you won't be able
to provide a reference implementation without also putting NBD_OPT_GO
suppo
or at least have implementations
* Uncontroversial, minimally impacting
* Reduction in the number of branches
Factors against:
* No kernel implementation to my knowledge, but I don't
think that's a killer
Wouter and anyone else - any objections / views?
--
> On 14 Dec 2016, at 16:58, Eric Blake wrote:
>
> s/botht he/both the/
Thanks - fixed
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Check out the vibrant tech com
#x27; or similar. So that's less of a problem. And 'set all' doesn't exist
(unlike 'list all').
I think in the LIST case we should allow the server to omit contexts under
certain circumstances, and allow SET to return ETOOBIG.
--
Alex Bligh
-
a "REQ_ONE" flag and a length field of zero could be an
> interesting way to enumerate a whole export, too. Essentially, we could
> define that as a client saying "I'm interested in what the size of the
> extent at offset X is, and what its properties are".
Als
ro length list of queries) does. It's currently defined to return every
context from every namespace. Options would include
* ETOOBIG
* Listing some subset of available contexts (arguably 'none' is a subset)
* Allowing abbreviation of algorithmically specified contexts (e.g. in th
good.
Let me have a go at a change.
However, note that Vladimir was answering a slightly different question.
I was asking about listing ALL contexts (previously an empty query
string, now a zero length list of queries), not a 'backup:*' type
thing.
--
Alex Bligh
--
e implementation of WRITE_ZEROES encounter any issues with the spec that
> we might want to fix up? Or did things work out as expected?
It was fine in nbdserver, and also fine in gonbdserver. Admittedly
I didn't have a 'rea
> On 14 Dec 2016, at 18:18, Alex Bligh wrote:
>
> Let me have a go at a change.
OK I've pushed a change. I reordered a few bits (to put the
base:allocation next to the stuff that talks about metadata
queries at the start), but the main change is below.
--
Alex Bligh
@@ -9
> On 14 Dec 2016, at 18:51, Eric Blake wrote:
>
> It's working well in qemu 2.8 without needing tweaks to the
> documentation. Should we try and do some cross-implementation testing
> today, before doing the actual merge?
If you have a minute to do so, that would be g
the spec for that and
know that it has X-Backup:modified if so'. So I've suggested it
return 'X-Backup:' only in that case, in which case from that
(*and the spec*) you know how to build any query.
--
Alex Bligh
-
For example,
> I'm eblake on freenode's #kvm channel.
Sure. I'm normally alexbligh or alexbligh1 on freenode or OFTC (where I'm
on #qemu). However I'm travelling Thurs through lands of little
connectivity. I'll try to remember to leave the IRC client running whe
ocket);
> + if (dontfork) {
> + acl = 'Y';
> + } else {
> + len = strlen(client->server->servename);
> + writeit(commsocket, &len, sizeof len);
> + writeit(commsocket, client->server->servename, len);
> +
ing configure time. Use the preferred
> substitution style for ALL variables, not just CFLAGS.
Seems like a good plan, though my automake reading skills
aren't what they were, and right now I'm compiling on a mac,
so
her than N or X to get the readit() to succeed.
>
> Looks like commit 7e901617 is the culprit, and maybe the solution is to
> just skip the commsocket stuff when -d is active (should -d also imply
> maxconnections of 1?).
Ah. Apologies for reading your emails out of order. This is
255 bytes). This may be helpful where a client can
construct algorithmic queries. For instance, a client might
reply simply with the namespace with no leaf-name (e.g.
'X-FooBar:') or with a range of values (e.g.
'X-ModifiedDate:20160310-20161214'). The semant
t;
> Why restrict to non-whitespace characters? (printable makes sense...)
Because the namespaces and leaf-names are already restricted to
non-whitespace characters. I thought having tabs, line feeds,
returns, em-space, en-space etc. was not particularly useful.
I could be persuaded to relent re
> On 15 Dec 2016, at 15:53, Eric Blake wrote:
>
> Unused since commit 6c2d8511. Be the chainsaw mentioned in the comment :)
>
> Signed-off-by: Eric Blake
Signed-off-by: Alex Bligh
Will wait for Wouter's say so before applying, given the
chain-saw nature.
Alex
>
> On 14 Dec 2016, at 20:19, Wouter Verhelst wrote:
>
> That's good enough for me, thanks.
I have now merged this. WRITE_ZEROES is now part of the main
NBD specification.
--
Alex Bligh
--
Check o
idea.
So to be clear do you want to include all whitespace
everywhere? Or just to the right of the colon in queries?
--
Alex Bligh
--
Check out the vibrant tech community on one of the world's
outer Verhelst
>
> I won't have time to merge and commit much tonight anymore, but feel
> free, Alex.
Done. I actually chopped out a bit more (SEND and ERROR macros).
--
Alex Bligh
--
Check out the vibr
g_array_append_val(retval, s);
> }
> --
> 2.9.3
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites
> On 16 Dec 2016, at 15:52, Wouter Verhelst wrote:
>
> On Thu, Dec 15, 2016 at 05:34:48PM +0000, Alex Bligh wrote:
>>
>>> On 15 Dec 2016, at 16:49, Wouter Verhelst wrote:
>>>
>>>> Because the namespaces and leaf-names are already restricted to
>
arguments, but
> they'd have to be very good ones ;-)
But we were at cross purposes. I was talking about the return from
queries, and you've adjusted namespaces (in toto). I've fixed up
your edit slightly, and brought the return for querie
ch, though, so you'll
> want to double-check that aspect of it (I basically hardcoded -d to mean
> that the ACL check would always succeed).
Yeah that was my reason for not merging it.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
pthread_mutex_unlock(&(client->lock));
> }
>
> I'm going to have to do a 3.15.1 for that, otherwise WRITE_ZEROES
> handling will be broken with TLS enabled.
Sorry, that was me I think (possibly or possibly n
sn't help much to add a flag here.
I agree.
Vladimir: if this isn't clear from the text, please suggest a change.
--
Alex Bligh
--
Check out the vibrant tech communi
ore metadata
> contexts with the NBD_OPT_SET_META_CONTEXT command. If needed, the
> client can use NBD_OPT_LIST_META_CONTEXT to list contexts that the
> server supports.
That still seems correct.
--
Alex Bligh
--
Check ou
eady have a read loop. If we don't then the 'one chunk'
method is perfectly acceptable. If I implemented structured replies at all, I'd
be sharing the code between multiple users in any case.
--
Alex Bligh
---
is Wouter's wording, but I think 'a status appropriate to the
context' would be better. Each context then needs to define what that is.
Either that or 'the context's default status' and that should be in the
definition of the context.
--
Alex Bligh
#x27;ve changed this to:
of the file), a server MAY reply with a single block status
descriptor with *length* matching the requested length, rather than
reporting the error; in this case the context MAY mandate the
status ret
>> replies followed by NBD_REP_ACK.:
> NBD_REP_ERR_UNSUP for the case in braces? Should it be normal option reply
> packet?
Thanks, fixed.
--
Alex Bligh
--
Developer Access Program for Intel Xeon Phi Proce
mand,
let alone a resize command. The size of an NBD disk is (currently)
entirely in the hands of the server. What I think we'd really need
would be a 'reread size' command, and have the server capable of
supporting resizing. That would then work for readonly images too.
--
Alex Bligh
NFO stuff to be reread.
If it's just this (rather than a resize command) I guess it could
go into the NBD_OPT_INFO extension branch. If it's going to do
more than _INFO_, then I guess it needs its own extension.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP us
> On 13 Jan 2017, at 09:48, Vladimir Sementsov-Ogievskiy
> wrote:
>
> 12.01.2017 16:11, Alex Bligh wrote:
>>> On 12 Jan 2017, at 07:05, Vladimir Sementsov-Ogievskiy
>>> wrote:
>>>
>>> Yes this is better. But is it actually needed to force
> On 14 Jan 2017, at 14:48, Wouter Verhelst wrote:
>
> On Thu, Jan 12, 2017 at 06:56:42PM +0000, Alex Bligh wrote:
>> My preferred way to do this would be essentially to allow NBD_OPT_INFO
>> to be sent (wrapped appropriately) during the main transmission phase.
>>
nbd_set_size args
>
> It'll be in 4.10. Thanks,
Interestingly enough, this is a regression, as the random 3.x kernel I tried
did not show the issue.
Thanks for the fix Josef.
--
Alex Bligh
--
D
avily.
I'm not sure sending 4,096 items for an empty 16TB disk is any great hardship
to be honest.
--
Alex Bligh
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slas
citly say people should know the implications
of using extensions in shipping code - specifically that the
specification may change!
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Chec
tter if possible
to stick with ioctls, and not introduce either a dependency
on netlink (which would presumably bloat static binaries that
are used early in the boot process). Personally I'd have thought
adding a new NBD ioctl (or extending an existing one) would be
less ent
blocksizes properly for the underlying device. Fix this up by
> setting the queue blocksizes and then calling bd_set_size.
Interesting. Some input into the info extension (re blocksizes) would
definitely be ap
> be relevant to this patch.
Indeed. Specifically, review of the patch from a kernel perspective
would be useful.
--
Alex Bligh
--
Check out the vibrant tech community on o
damentally relies on a certain amount
of connection state, as negotiated during the negotiation phase.
I think the stateless/non-stateless question is not necessarily linked
with UDP/TCP (as demonstrated by the fact that NFSv4 runs over both
happily).
--
Alex Bligh
--
ike a dozen
> people in the world who think they really understand all of its rules,
> and pretty much all of them are just lying to themselves too.
> -- #debian-devel, OFTC, 2016-02-12
>
> --
> Check out the vibrant te
ling the INFO/GO messages easier to do.
>
> Signed-off-by: Wouter Verhelst
Acked-by: Alex Bligh
> ---
> doc/proto.md | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/proto.md b/doc/proto.md
> index 92df086..8712626 100644
> --- a/doc/pro
#block-size-constraints
These are server block sizes (obviously) which would normally be passed
from userland client to kernel client via an ioctl. I suspect such
ioctls may not be implemented at the moment, and kernel support for
them would be muc
> nbd-client and nbd-server as well).
>
> I'm not going to release a new version of NBD just yet, but thought I'd
> give everyone a heads-up.
Excellent! Did you perchance try against gonbdserver? If no
wan,
>
> In that case, you're stacking TCP over TCP, which does not work very
> well. See http://sites.inka.de/~W1011/devel/tcp-tcp.html for a pretty
> good (technical) explanation on why that is the case.
I don't think that's write. nbd ov
___
> Nbd-general mailing list
> Nbd-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general
--
Alex Bligh
--
Check out the vibrant tech community on one of the world's mo
no bad thing, but people should be aware of this as it is (I believe,
correct me if I am wrong) a consequence of the move. Note the code
of conduct thing isn't a contributor agreement or whatever, it is
in essence a statement that you should be respectful to people on
the list and therefore s
just thought we should let people know it will (I think) apply.
--
Alex Bligh
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_
could subscribe an autoresponder pointing at the new list?
--
Alex Bligh
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_
the option data and into the option header (obviously there is
no code change required). This will allow servers to skip options
presented by clients that the server does not understand.
--
Alex Bligh
Signed-off-by: Alex Bligh
diff --git a/doc/proto.txt b/doc/proto.txt
index aa247af..fe5e819
th exit status: 1
I think the attached is the right patch (well, I have ./configure
now). There may be a prettier way of doing it (e.g. putting an
"infiles" target into man/Makefile.am) but this is least intrusive.
--
Alex Bligh
Signed-off-by: Alex Bligh
diff --git a/autogen.sh b/autoge
other possibility would be to set (e.g.) the top bit of the option
number to mean "error if you don't understand this", which would be
rather less fine-grained.
--
Alex Bligh
--
Achieve unprecedented app
whether I'm doing this
in a vaguely useful way. I repeat the point about this code not being
tested at all beyond compilation.
Clean version of patch at
http://www.alex.org.uk/nbd-flush-fua-01.patch
in case my mailer mangles newlines
--
Alex Bligh
Signed-Off-By: Alex Bligh
diff --gi
ous whitespace change.
Fixed
> This file is taken from the kernel, so should probably be patched there
> rather than here (though of course it would be hard to compile-test
> without these bits).
Sure. Though I /think/ for proper compilation it needs to be fixed
in both places, yes?
> Pl
line 215 is superfluous. The flags should
simply be converted to host order, and assigned to "flags", so
they will live in least significant two bytes (where they came
from).
--
Alex Bligh
--
Achieve unprecedent
g that to a switch is indeed the most sensible thing to do.
OK, I might refactor that then.
> Okay; I'll hold off on applying this until that's been done.
That is wise :-)
> If relevant and possible, I'd appreciate it if you could also add
--On 16 May 2011 17:29:37 +0100 Alex Bligh wrote:
> I think the "<< 16" on line 215 is superfluous. The flags should
> simply be converted to host order, and assigned to "flags", so
> they will live in least significant two bytes (where they came
> from)
1 - 100 of 693 matches
Mail list logo
