#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".
Also +1
--
Alex Bligh
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 this
case just returning 'backup:' to represent all available backup contexts)
--
Alex Bligh
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
> 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
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
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 semantics of
such a reply are a matter for the definition of the
namespace.
Hope that works.
--
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
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
> 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 queries in line
with it. I hope this nit is now dead!
--
Alex Bligh
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
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
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
ole 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 size'.
This could then be defined to work with all commands.
--
Alex Bligh
multiple of the minimum block size. So that would work.
--
Alex Bligh
ou can pretty much
assume that a server that supports holes will write holes. A server that does
not support holes will write zeroes. If you don't care whether the resultant
data is zero, just use NBD_CMD_TRIM. But as you do care (see above) you must be
prepared for a 'thick' write of zeroes on servers that don't support it.
--
Alex Bligh
> On 24 Sep 2016, at 17:42, Vladimir Sementsov-Ogievskiy
> wrote:
>
> On 24.09.2016 19:31, Alex Bligh wrote:
>>> On 24 Sep 2016, at 13:06, Vladimir Sementsov-Ogievskiy
>>> wrote:
>>>
>>> Note: if disk size is not aligned to X we will have t
gy, 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:52, Alex Bligh 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 should also be aw
> On 24 Sep 2016, at 18:13, Vladimir Sementsov-Ogievskiy
> wrote:
>
> On 24.09.2016 19:49, Alex Bligh wrote:
>>> On 24 Sep 2016, at 17:42, Vladimir Sementsov-Ogievskiy
>>> wrote:
>>>
>>> On 24.09.2016 19:31, Alex Bligh wrote:
>>>
ou 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
s
> + not specified. If after shift `(offset + length)` exceeds disk size, length
> + should be reduced to `( - offset)`. However, `(offset + length)`
> + must not exceed disk size by more than `(1 << N) - 1`.
Is there a good reason the shift size can't be either the minimum block size
or otherwise negotiated using NBD_OPT_INFO?
--
Alex Bligh
do by mistake!
This whole 'clear the whole disk in one command' seems like a
dire case of premature optimisation.
--
Alex Bligh
> On 27 Sep 2016, at 00:41, Wouter Verhelst 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
ing timerlistgroup_deadline_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
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 returned.
--
Alex Bligh
>> 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
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 using GPGMail
> 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
t'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
BD_CMD_WRITE_ZEROES because it doesn'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 10 Feb 2018, at 18:43, Alex Bligh 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 offset).
Ur actually
901 - 935 of 935 matches
Mail list logo
