> On 8 Dec 2016, at 06:58, Vladimir Sementsov-Ogievskiy
> wrote:
>
> An idea: let's not use uppercase. Why to shout the namespace? 'base' and 'x-'
> would be better I think. BASE and X- will provoke all user-defined namespaces
> be in uppercase too and a lot of
08.12.2016 06:39, Alex Bligh wrote:
[...]
are vendor dependent extensions. The 'BASE' namespace represents
metadata contexts defined within this document. Other namespaces
may be registered by reference within this document.
+The "BASE:allocation"
Backticks: `BASE:allocation`
An idea:
> 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,
02.12.2016 23:39, John Snow wrote:
On 12/02/2016 01:45 PM, Alex Bligh wrote:
John,
+Some storage formats and operations over such formats express a
+concept of data dirtiness. Whether the operation is block device
+mirroring, incremental block device backup or any other operation with
+a
> On 2 Dec 2016, at 20:39, John Snow wrote:
>
> OK. We do certainly support multiple bitmaps being active at a time in
> QEMU, but I had personally always envisioned that you'd associate them
> one-at-a-time when starting the NBD export of a particular device.
>
> I don't
On 12/02/2016 01:45 PM, Alex Bligh wrote:
> John,
>
>>> +Some storage formats and operations over such formats express a
>>> +concept of data dirtiness. Whether the operation is block device
>>> +mirroring, incremental block device backup or any other operation with
>>> +a concept of data
John,
>> +Some storage formats and operations over such formats express a
>> +concept of data dirtiness. Whether the operation is block device
>> +mirroring, incremental block device backup or any other operation with
>> +a concept of data dirtiness, they all share a need to provide a list
>> +of
02.12.2016 02:42, John Snow wrote:
(B) In the case of "User just wanted to look around," the bitmap should
be merged back into the bitmap it was forked from.
currently existing example: "failed incremental backup"
--
Best regards,
Vladimir
Hi Alex, let me try my hand at clarifying some points...
On 11/29/2016 07:57 AM, Alex Bligh wrote:
> Vladimir,
>
> I went back to April to reread the previous train of conversation
> then found you had helpfully summarised some if it. Comments
> below.
>
> Rather than comment on many of the
29.11.2016 17:52, Alex Bligh wrote:
Vladimir,
4. Q: Should not get_{allocated,dirty} be separate commands?
cons: Two commands with almost same semantic and similar means?
pros: However here is a good point of separating clearly defined and native
for block devices
Vladimir,
>>> 4. Q: Should not get_{allocated,dirty} be separate commands?
>>> cons: Two commands with almost same semantic and similar means?
>>> pros: However here is a good point of separating clearly defined and
>>> native
>>> for block devices GET_BLOCK_STATUS from user-driven
29.11.2016 15:57, Alex Bligh wrote:
Vladimir,
I went back to April to reread the previous train of conversation
then found you had helpfully summarised some if it. Comments
below.
Rather than comment on many of the points individual, the root
of my confusion and to some extent
Vladimir,
I went back to April to reread the previous train of conversation
then found you had helpfully summarised some if it. Comments
below.
Rather than comment on many of the points individual, the root
of my confusion and to some extent uncomfortableness about this
proposal is 'who owns the
On Fri, Nov 25, 2016 at 02:28:16PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> With the availability of sparse storage formats, it is often needed
> to query status of a particular range and read only those blocks of
> data that are actually present on the block device.
>
> To provide such
With the availability of sparse storage formats, it is often needed
to query status of a particular range and read only those blocks of
data that are actually present on the block device.
To provide such information, the patch adds the BLOCK_STATUS
extension with one new NBD_CMD_BLOCK_STATUS
15 matches
Mail list logo