s (by default), but it's
> something you can configure on your system if you need it to be lower.
+1 for just using SO_KEEPALIVE. I think I even submitted some (untested
and thus unmerged) patches for this.
--
Alex Bligh
> On 10 Feb 2018, at 18:43, Alex Bligh <a...@alex.org.uk> wrote:
>
> So I think a reasonable logic for Qemu would be to try NBD_CMD_INFO and find
> the maximum write size, and if that's unsupported use 0x (capping at
> export size, or export size minus write
n't have a payload, I
think the rebuttal is that a server which supports NBD_CMD_WRITE of a given
length must also support NBD_CMD_WRITE_ZEROES of that length.
So I think a reasonable logic for Qemu would be to try NBD_CMD_INFO and find
the maximum write size, and if that's unsupported use 0x (capping at
export size, or export size minus write offset).
--
Alex Bligh
> On 3 Oct 2017, at 15:45, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
> Alex (both of them), Sergio, anyone else who can help?
Very interested in this (and thanks!) but it will be a while
before I have a sensible number of cycles available to play
with this one again.
--
Alex Bligh
fair
(fine), we explicitly 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
orse). This
is baked into the specification heavily.
I'm not sure sending 4,096 items for an empty 16TB disk is any great hardship
to be honest.
--
Alex Bligh
> On 14 Jan 2017, at 14:48, Wouter Verhelst <w...@uter.be> 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 transm
> On 13 Jan 2017, at 09:48, Vladimir Sementsov-Ogievskiy
> <vsement...@virtuozzo.com> wrote:
>
> 12.01.2017 16:11, Alex Bligh wrote:
>>> On 12 Jan 2017, at 07:05, Vladimir Sementsov-Ogievskiy
>>> <vsement...@virtuozzo.com> wrote:
>>>
>>
ize 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 using GPGMail
command,
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
list of NBD_REP_META_CONTEXT
>> 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
should it be requirement at all?
I'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 returned.
--
Alex Bligh
all.
I think this 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
ine_ns rather than
qemu_clock_deadline_ns_all.
The comment at the top of qemu_clock_deadline_ns_all says:
/* Calculate the soonest deadline across all timerlists attached
* to the clock. This is used for the icount timeout so we
* ignore whether or not the clock should be used in deadline
* calculations.
*/
I'm wondering whether there is something up with that logic.
--
Alex Bligh
emory), so we already 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
t; 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
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
od 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 queries in line
with it. I hope this nit is now dead!
--
Alex Bligh
> On 16 Dec 2016, at 15:52, Wouter Verhelst <w...@uter.be> wrote:
>
> On Thu, Dec 15, 2016 at 05:34:48PM +0000, Alex Bligh wrote:
>>
>>> On 15 Dec 2016, at 16:49, Wouter Verhelst <w...@uter.be> wrote:
>>>
>>>> Because the namespaces and
a good 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
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 spaces.
--
Alex Bligh
such a reply are a matter for the definition of the
namespace.
Hope that works.
--
Alex Bligh
'X-Backup:' only in that case, in which case from that
(*and the spec*) you know how to build any query.
--
Alex Bligh
> On 14 Dec 2016, at 18:18, Alex Bligh <a...@alex.org.uk> 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.
hange.
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
OBIG
* Listing some subset of available contexts (arguably 'none' is a subset)
* Allowing abbreviation of algorithmically specified contexts (e.g. in this
case just returning 'backup:' to represent all available backup contexts)
--
Alex Bligh
; 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".
Also +1
--
Alex Bligh
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
> On 14 Dec 2016, at 16:58, Eric Blake <ebl...@redhat.com> wrote:
>
> s/botht he/both the/
Thanks - fixed
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
ding 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
support into the reference implementation. Oh hang on, perhaps that's
an advantage :-)
So I'd either go with #0 or #3.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
ocks 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
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 <a...@alex.org.uk>
---
doc/proto.md
lear, it should still 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
lear MUST NOT fail with ENOSPC
unless for reasons specified in the definition of another context."
>>> +For the `base:allocation` context, the remainder of the flags field is
>>> +reserved. Servers SHOULD set it to all-zero;
>>
>> Surely if we want to reserve them for extension, we need "Servers
>> MUST set it to all-zero"
>
> No, SHOULD, otherwise a future extension which adds meaning to those
> bits will suddenly become incompatible with this spec. Think about it
> ;-)
I did! If there is a future extension, it will change the spec to
incorporate those bits, so they won't be included within 'the
remainder' any more.
> (feel free to update the branch with those suggestions I've not NAK'd,
> as I think they make sense...)
OK. May take a look later.
--
Alex Bligh
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 limitation.
I don't think it's as bad as the structured reply fix, and could conceivably
go in there.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
ations can register additional
> + 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
he error field of an error chunk. However, if the error
> +does not involve invalid usage (such as a request beyond the bounds
> +of the file), a server MAY reply with a single block status
> +descriptor with *length* matching the requested length, and *status*
> +of 0 rather than reporting the error.
> +
> +A client MAY initiate a hard disconnect if it detects that the
> +server has sent an invalid chunk. The server SHOULD return `EINVAL`
> +if it receives a `NBD_CMD_BLOCK_STATUS` request including one or
> +more sectors beyond the size of the device.
> +
> * Other requests
>
> Some third-party implementations may require additional protocol
>
> --
> < ron> I mean, the main *practical* problem with C++, is there's like 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 tech community on one of the world's most
> engaging tech sites, SlashDot.org!
> http://sdm.link/slashdot___
> Nbd-general mailing list
> nbd-gene...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
flags" field, 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 <a...
t you logically
> get 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
ast bit in brackets. Rather than saying
a client SHOULD NOT read it, it should simply say that a read on
such areas will succeed but the data read is undefined (and may
not be stable).
> My WIP patch moves this out from the (older) "BLOCK_STATUS extension"
> section and into the main body of the spec. It also makes a few changes
> in wording as per what Vladimir suggested, and I was working on an
> NBD_OPT_LIST_META_CONTEXT rather than an NBD_OPT_META_CONTEXT
> negotiation option, with the idea that I'd add an OPT_ADD_META_CONTEXT
> and an OPT_DEL_META_CONTEXT later. Your idea of using a SET has merit
> though, so I'll update it to that effect.
>
> It already removed the two bits that BASE:allocation doesn't use, and
> makes a few other changes as well. I haven't had the time to finish it
> and send it out for review though, but I'll definitely include your
> comments now.
Thanks.
--
Alex Bligh
uppercase too and a lot of uppercase will come to the code =(
I agree
--
Alex Bligh
> On 2 Dec 2016, at 18:45, Alex Bligh <a...@alex.org.uk> 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
> On 6 Dec 2016, at 08:46, Alex Bligh <a...@alex.org.uk> 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 Bligh <a...@alex.org.uk>
--
Alex Bligh
nd I see no issue passing complete
zero status back to the client if it's so obvious from a stat().
--
Alex Bligh
___
> Nbd-general mailing list
> nbd-gene...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general
>
--
Alex Bligh
ased).
I tried to pick some QEMU-like ones, but I am sure there are
examples that would work outside of QEMU.
--
Alex Bligh
g difficulty conveying precisely what it is we're
> trying to accomplish, so I hope that I am making a good effort in
> elaborating on our goals/requirements.
Yes absolutely. I think part of the challenge is that you are quite
reasonably coming at it from the point of view of qemu's particular
need, and I'm coming at it from 'what should the nbd protocol look
like in general' position, having done lots of work on the protocol
docs (though I'm an occasional qemu contributor). So there's necessarily
a gap of approach to be bridged.
I'm overdue on a review of Wouter's latest patch (partly because I need
to re-diff it against the version with no NBD_CMD_BLOCK_STATUS in),
but I think it's a bridge worth building.
--
Alex Bligh
f 1024 extents per
reply), this isn't going to noticeably increase the round trip timing. One
issue here is that to determine a 'reasonable' size, the client needs to know
the minimum length of any extent.
I think the answer is probably a 'maximum number of extents' in the request
packet.
Of course with statuses in extent, the final extent could be represented as 'I
don't know, break this bit into a separate request' status.
--
Alex Bligh
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
first and last descriptor of an unaligned query being
> +the most obvious places for an exception).
Surely better would be an an integer multiple of the minimum block
size. Being able to offer bitmap support at finer granularity than
the absolute minimum block size helps no one, and if it were possible
to support a 256 byte block size (I think some floppy disks had that)
I see no reason not to support that as a granularity.
--
Alex Bligh
> On 27 Sep 2016, at 00:41, Wouter Verhelst <w...@uter.be> wrote:
>
> Thoughts?
Honestly? This whole thing seems like complication for little gain. One command
per 2GB wiped doesn't seem like a bad thing.
--
Alex Bligh
ntire
disk easy to do by mistake!
This whole 'clear the whole disk in one command' seems like a
dire case of premature optimisation.
--
Alex Bligh
ize can't be either the minimum block size
or otherwise negotiated using NBD_OPT_INFO?
--
Alex Bligh
ise you not to use more than
2^31). And in any case, you probably want to parallelise reads and writes and
have more than one write in flight in any case, all of which suggests you are
going to be breaking up requests anyway.
--
Alex Bligh
> On 24 Sep 2016, at 18:13, Vladimir Sementsov-Ogievskiy
> <vsement...@virtuozzo.com> wrote:
>
> On 24.09.2016 19:49, Alex Bligh wrote:
>>> On 24 Sep 2016, at 17:42, Vladimir Sementsov-Ogievskiy
>>> <vsement...@virtuozzo.com> wrote:
>>>
>
> On 24 Sep 2016, at 17:52, Alex Bligh <a...@alex.org.uk> wrote:
>
> In *your* use-case holes may be desirable. However in the general case, you
> cannot assume a server supports holes. Optional support for holes isn't even
> in the mainline spec yet (AFAIR).
You
egy, you
cannot guarantee that the server will not implement them by ignoring
NBD_CMD_TRIM (this is perfectly acceptable as NBD_CMD_TRIM is advisory only)
and making NBD_CMD_WRITE_ZEREOS do a long write of zeroes.
IE there is no way to detect whether the server actually supports holes.
--
Alex Bligh
> On 24 Sep 2016, at 17:42, Vladimir Sementsov-Ogievskiy
> <vsement...@virtuozzo.com> wrote:
>
> On 24.09.2016 19:31, Alex Bligh wrote:
>>> On 24 Sep 2016, at 13:06, Vladimir Sementsov-Ogievskiy
>>> <vsement...@virtuozzo.com> wrote:
>>>
>
for a 'thick' write of zeroes on servers that don't support it.
--
Alex Bligh
size of the disk must be an exact
multiple of the minimum block size. So that would work.
--
Alex Bligh
limited to "whole disk" commands. We should probably make it an illegal
> flag for any command that actually sends data over the wire, though.
I'd prefer an approach like this. Perhaps X could be negotiated
with the block size extension (or simply be defined as the
'preferred block
port.
XMM registers and FPState (for instance) appear to be in an opaque format:
https://developer.apple.com/library/mac/documentation/Hypervisor/Reference/Hypervisor_Reference/index.html#//apple_ref/c/func/hv_vcpu_read_fpstate
--
Alex Bligh
with the appropriate hv_ call) and ignore all the
other register futzing? Or is it more complicated than that
because (presumably) something sets up register states in the
cpu->regs, cpu->sregs areas? I'm a bit confused as to how all
this works to be honest. Any ideas / docs to point to?
--
Alex Bligh
uot; if we want to go down this route.
--
Alex Bligh
send a payload.
>
> In other words, the current behaviour of qemu is correct, is now
> documented to be correct, and should not be changed.
So what should those servers do (like 2 of mine) which don't buffer
the entire read, if they get an error having already sent some data?
--
A
en reasonably well known (I wrote about it
at least 3 years ago), that the current implementation
(reference + kernel) does not cope well with errors
on reads, so I'm guessing one is just trading one
set of brokenness for another. So I'm pretty relaxed
about what goes in qemu.
--
Alex Bligh
On 14 Jun 2016, at 14:32, Paolo Bonzini <pbonz...@redhat.com> 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
>> implement that for
ub.com/yoe/nbd/blob/master/nbd-server.c#L1734
In essence read error handling is a horrible mess in NBD, and
I would not expect it to work in general :-(
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 6 Jun 2016, at 13:29, Alex Bligh <a...@alex.org.uk> wrote:
> Is anyone working on support for hypervisor.framework (OS-X's equivalent to
> kvm as far as I can see)?
>
> If not, I might have a go in my copious spare time (cough) and if anyone
> would be interesting
Peter,
On 6 Jun 2016, at 13:43, Peter Maydell <peter.mayd...@linaro.org> wrote:
> Not that I am aware of.
>
> Previous discussion:
> https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg03086.html
Thanks. Missed that due to "Framwork" spelling!
--
Alex Bligh
has support for this, and its license is described as "BSD" (that's it). Is
that Qemu GPL compatible? Though I suspect a clean implementation may be easier.
--
Alex Bligh
a lower number.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
to fix it, so I think
we should fix the software to confirm to the standard, not the
standard to conform to the software.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 17 May 2016, at 16:54, Richard W.M. Jones <rjo...@redhat.com> wrote:
> On Tue, May 17, 2016 at 04:22:06PM +0100, Alex Bligh wrote:
>> nbdkit is non-compliant in that case. Support of NBD_OPT_LIST is
>> compulsory, even if you support it by returning a nameless export
>
On 17 May 2016, at 16:52, Eric Blake <ebl...@redhat.com> wrote:
> On 05/17/2016 09:22 AM, Alex Bligh wrote:
>
>>>> nbdkit's implemention of NBD_OPT_LIST returns an error, because there
>>>> is no such thing as a list of export names supported (in effec
esn't have anything it can export'.
>> Naturally the protocol document
>> (https://github.com/yoe/nbd/blob/master/doc/proto.md) isn't clear on
>> this case.
>
> You're right that we may also want to tweak the NBD protocol to make
> this interoperability point obvious.
I can't actually see the issue here. It explains what needs to be
implemented by the server, and that includes NBD_OPT_LIST. Very
happy to add some clarity, but I'm not sure where it's needed.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 11 May 2016, at 22:06, Wouter Verhelst <w...@uter.be> wrote:
> 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
>>
k good to me.
--
Alex Bligh
On 11 May 2016, at 22:12, Wouter Verhelst <w...@uter.be> wrote:
> On Tue, May 10, 2016 at 04:38:29PM +0100, Alex Bligh wrote:
>> On 10 May 2016, at 16:29, Eric Blake <ebl...@redhat.com> wrote:
>>> So the kernel is currently one of the clients that
ROES are orthogonally optional).
...
at this rate you'd be better with a list of command / maximum size
tuples!
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
this would work /with/ the block
size extensions, as Eric is in the process of implementing them).
> I do agree with your point number 3, obviously if the lenght
> field type doesn't allow something bigger than a u32, then the kernel has
> to do some breaking up in that case.
--
Alex Bligh
(1) with -p ?
http://man7.org/linux/man-pages/man1/fallocate.1.html
As it takes length and offset in TB, PB, EB, ZB and YB, it
seems to be 64 bit aware :-)
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
kernel needs to do at least
some breaking up.
--
Alex Bligh
ize constraints or not, it is
going to need to do *some* breaking up of requests.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
ther way?
>
> No extension in play. The kernel is obeying NBD_FLAG_SEND_TRIM, which
> is in the normative standard, and unrelated to the INFO/BLOCK_SIZE
> extensions.
My mistake. I was confusing 'WRITE_ZEROES' with 'TRIM'.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
-
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
> Nbd-general mailing list
> nbd-gene...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
r servers.
I'm going to find a minimal patch to nbd-client and offer that
to Ubuntu / Debian.
This message is here in part so I have something to point them at
on the mailing list :-)
--
Alex Bligh
it won't play
nicely with all the other stuff you've been doing).
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
> info->size);
> return -E2BIG;
> }
> @@ -724,18 +784,18 @@ int nbd_init(int fd, QIOChannelSocket *sioc,
> NbdExportInfo *info)
> return -serrno;
> }
>
> -TRACE("Setting block size to %lu", (unsigned long)BDRV_SECTOR_SIZE);
> +TRACE("Setting block size to %lu", sector_size);
>
> -if (ioctl(fd, NBD_SET_BLKSIZE, (unsigned long)BDRV_SECTOR_SIZE) < 0) {
> +if (ioctl(fd, NBD_SET_BLKSIZE, sector_size) < 0) {
> int serrno = errno;
> LOG("Failed setting NBD block size");
> return -serrno;
> }
>
> TRACE("Setting size to %lu block(s)", sectors);
> -if (size % BDRV_SECTOR_SIZE) {
> -TRACE("Ignoring trailing %d bytes of export",
> - (int) (size % BDRV_SECTOR_SIZE));
> +if (info->size % sector_size) {
> +TRACE("Ignoring trailing %" PRId64 " bytes of export",
> + info->size % sector_size);
> }
>
> if (ioctl(fd, NBD_SET_SIZE_BLOCKS, sectors) < 0) {
> --
> 2.5.5
>
>
--
Alex Bligh
Eric,
See my message on nbd-general today re the necessity (or not)
of getting NBD_OPT_BLOCK_SIZE first; it may be just that you
can assume 512 is OK.
Otherwise
Reviewed-by: Alex Bligh <a...@alex.org.uk>
Alex
On 23 Apr 2016, at 00:40, Eric Blake <ebl...@redhat.com> wrote:
> T
block code takes care of falling back to the obvious
> write of lots of zeroes if we return -ENOTSUP because the server
> does not have WRITE_ZEROES.
>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Alex Bligh <a...@alex.org.uk>
>
> ---
> v3: rebase
f-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Alex Bligh <a...@alex.org.uk>
>
> ---
> v3: abandon NBD_CMD_CLOSE extension, rebase to use blk_pwrite_zeroes
> ---
> include/block/nbd.h | 7 +--
> nbd/server.c| 42
es (including when a server
> requires TLS but does not have NBD_OPT_GO!), and on success
> it provides at least as much info as NBD_OPT_EXPORT_NAME sends.
>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
>
Reviewed-by: Alex Bligh <a...@alex.org.uk>
> ---
>
case NBD_OPT_ABORT:
> -return -EINVAL;
> + /* NBD spec says we must reply before disconnecting,
> + * but that we must also tolerate guests that don't
> + * wait for our reply. */
> +ret = nbd_negotiate_send_rep(client->ioc, NBD_REP_ACK,
> + clientflags);
> +if (!ret) {
> +ret = -EINVAL;
> +}
> +return ret;
>
> case NBD_OPT_EXPORT_NAME:
> return nbd_negotiate_handle_export_name(client, length);
> --
> 2.5.5
>
>
--
Alex Bligh
> Signed-off-by: Eric Blake <ebl...@redhat.com>
> Reviewed-by: Alex Bligh <a...@alex.org.uk>
>
> ---
> v3: rebase, tweak a debug message
> ---
> include/block/nbd.h | 29 +-
> nbd/nbd-internal.h | 2 +-
> nbd/client.c| 250 +++
-off-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Alex Bligh <a...@alex.org.uk>
>
> ---
> v3: rebase to changes earlier in series
> ---
> nbd/server.c | 48 +++-
> 1 file changed, 23 insertions(+), 25 deletions(-)
>
&
nts in nbd.h based on the current upstream
> NBD protocol (https://github.com/yoe/nbd/blob/master/doc/proto.md),
> and touch some nearby code to keep checkpatch.pl happy.
>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Alex Bligh <a...@alex.org.uk>
>
> ---
1024). So for now, just
> stick to the required minimum.
>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Alex Bligh <a...@alex.org.uk>
>
> ---
> v3: enlarge the limit, and document choice of new value
> ---
> include/block/nbd.h | 6 ++
> nbd/cl
t; -goto out;
> +/* unreachable, thanks to special case in nbd_co_receive_request() */
> +abort();
> +
> case NBD_CMD_FLUSH:
> TRACE("Request type is FLUSH");
>
> @@ -1182,10 +1203,14 @@ static void nbd_trip(void *opaque)
> break;
> default:
> LOG("invalid request type (%" PRIu32 ") received", request.type);
> -invalid_request:
> reply.error = EINVAL;
> error_reply:
> -if (nbd_co_send_reply(req, , 0) < 0) {
> +/* We must disconnect after replying with an error to
> + * NBD_CMD_READ, since we choose not to send bogus filler
> + * data; likewise after NBD_CMD_WRITE if we did not read the
> + * payload. */
> +if (nbd_co_send_reply(req, , 0) < 0 || command == NBD_CMD_READ
> ||
> +(command == NBD_CMD_WRITE && !req->complete)) {
> goto out;
> }
> break;
> --
> 2.5.5
>
>
--
Alex Bligh
also makes it easier to test commit 200650d4, which
> is the client counterpart of receiving the description.
>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Alex Bligh <a...@alex.org.uk>
> ---
> include/block/nbd.h | 1 +
> nbd/nb
1 - 100 of 933 matches
Mail list logo
