On 01/20/2017 12:00 PM, Alex Bligh wrote:
>
>> On 20 Jan 2017, at 17:04, Vladimir Sementsov-Ogievskiy
>> wrote:
>>
>> About extents: is 32bit length enough? We will have to send 4096 for empty
>> 16tb disk..
>
> The nbd protocol uniformly uses 32 bit lengths (for better or for worse).
> This
> On 20 Jan 2017, at 17:04, Vladimir Sementsov-Ogievskiy
> wrote:
>
> About extents: is 32bit length enough? We will have to send 4096 for empty
> 16tb disk..
The nbd protocol uniformly uses 32 bit lengths (for better or for worse). This
is baked into the specification heavily.
I'm not sure
About extents: is 32bit length enough? We will have to send 4096 for
empty 16tb disk..
--
Best regards,
Vladimir
13.01.2017 13:29, Alex Bligh wrote:
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 contexts have some safe
default? If co
> 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 contexts have some
>>> safe default? If context want
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 contexts have some safe
default? If context wants it may define such default without this requirement..
So, should it be requirement at all
> On 12 Jan 2017, at 11:43, Vladimir Sementsov-Ogievskiy
> wrote:
>
> From "NBD_OPT_LIST_META_CONTEXT (9)":
>> The server MUST either reply with an error (for instance EINVAL if the
>> option is not supported), or reply with a list of NBD_REP_META_CONTEXT
>> replies followed by NBD_REP_ACK.:
> On 12 Jan 2017, at 07:05, Vladimir Sementsov-Ogievskiy
> wrote:
>
> Yes this is better. But is it actually needed to force contexts have some
> safe default? If context wants it may define such default without this
> requirement.. So, should it be requirement at all?
I've changed this to:
(Sorry, it may be a bit out of topic, but I hope it is comfortable for
all that I just comment current version of the feature by answering
cover letter of last related patch set)
From |"NBD_OPT_LIST_META_CONTEXT| (9)":
The server MUST either reply with an error (for instance |EINVAL| if
the op
11.01.2017 22:00, Alex Bligh wrote:
On 11 Jan 2017, at 15:31, Vladimir Sementsov-Ogievskiy
wrote:
If an error occurs, the server SHOULD set the appropriate error code in the
error field of an error chunk. However, if the error does not involve invalid
usage (such as a request beyond the bou
> On 11 Jan 2017, at 15:31, Vladimir Sementsov-Ogievskiy
> wrote:
>
> >>> If an error occurs, the server SHOULD set the appropriate error code in
> >>> the error field of an error chunk. However, if the error does not involve
> >>> invalid usage (such as a request beyond the bounds of the fil
from current version:
>>> If an error occurs, the server SHOULD set the appropriate error
code in the 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
> On 27 Dec 2016, at 14:09, Vladimir Sementsov-Ogievskiy
> wrote:
>
> What was the reason for it? Why not to negotiate forced structured read
> separately? Actually, this spec forces any server, which wants to implement
> structured reply implement structured read too. But what if it don't wa
On 12/27/2016 08:09 AM, Vladimir Sementsov-Ogievskiy wrote:
> A bit out of topic, but...
>
>> structured replies via `NBD_OPT_STRUCTURED_REPLY`. Conversely, if
>> structured replies are negotiated, the server MUST use a
>> structured reply for any response with a payload, and MUST NOT use
>> a si
A bit out of topic, but...
structured replies via `NBD_OPT_STRUCTURED_REPLY`. Conversely, if
structured replies are negotiated, the server MUST use a
structured reply for any response with a payload, and MUST NOT use
a simple reply for `NBD_CMD_READ` (even for the case of an early
`EINVAL` due
14.12.2016 21:17, Alex Bligh wrote:
On 14 Dec 2016, at 17:55, Vladimir Sementsov-Ogievskiy
wrote:
Hmmm... Well in the '*' case, it's up to the namespace as to how it parses
things, so '*' could be prohibited entirely or mean 'return the first 20
matching' or similar. So that's less of a pro
> On 14 Dec 2016, at 17:55, Vladimir Sementsov-Ogievskiy
> wrote:
>
>> Hmmm... Well in the '*' case, it's up to the namespace as to how it parses
>> things, so '*' could be prohibited entirely or mean 'return the first 20
>> matching' or similar. So that's less of a problem. And 'set all' doe
14.12.2016 20:36, Alex Bligh wrote:
On 14 Dec 2016, at 17:05, Vladimir Sementsov-Ogievskiy
wrote:
However, this raises another question. Wouter deliberately made the
query format freeform so that you could e.g. set a context like:
backup:modtime>201612081034
which might (in theory) retur
14.12.2016 19:38, Alex Bligh wrote:
Vladimir,
+non-zero number of metadata contexts during negotiation. Servers SHOULD
+reply to clients sending `NBD_CMD_BLOCK_STATUS without
backquote
Fixed
+If zero queries are sent, then the server MUST return all
+the metadata contexts it knows a
> On 14 Dec 2016, at 17:05, Vladimir Sementsov-Ogievskiy
> wrote:
>>
>> However, this raises another question. Wouter deliberately made the
>> query format freeform so that you could e.g. set a context like:
>>
>>backup:modtime>201612081034
>>
>> which might (in theory) return a list of b
> 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
On 12/14/2016 09:08 AM, Alex Bligh wrote:
> (NB: I've already applied this and pushed it)
>
> * Change NBD_OPT_LIST_METADATA etc. to explicitly send a list of queries
> and add a count of queries so we can extend the command later (rather than
> rely on the length of option)
>
> * For NBD_OPT
Vladimir,
>> +non-zero number of metadata contexts during negotiation. Servers SHOULD
>> +reply to clients sending `NBD_CMD_BLOCK_STATUS without
>
> backquote
Fixed
>> +If zero queries are sent, then the server MUST return all
>> +the metadata contexts it knows about.
>
> I think that
14.12.2016 18:08, Alex Bligh wrote:
(NB: I've already applied this and pushed it)
* Change NBD_OPT_LIST_METADATA etc. to explicitly send a list of queries
and add a count of queries so we can extend the command later (rather than
rely on the length of option)
* For NBD_OPT_LIST_METADATA m
(NB: I've already applied this and pushed it)
* Change NBD_OPT_LIST_METADATA etc. to explicitly send a list of queries
and add a count of queries so we can extend the command later (rather than
rely on the length of option)
* For NBD_OPT_LIST_METADATA make absence of any query (as opposed to
25 matches
Mail list logo
