On 08.07.19 20:32, John Snow wrote:
>
>
> On 7/8/19 8:02 AM, Max Reitz wrote:
>> On 05.07.19 18:52, John Snow wrote:
>>>
>>>
>>> On 7/4/19 1:29 PM, Max Reitz wrote:
>>
>> [...]
>>
Which brings me to a question: Why is the copy bitmap assigned to the
target in the first place? Wouldn’t
On 7/8/19 8:02 AM, Max Reitz wrote:
> On 05.07.19 18:52, John Snow wrote:
>>
>>
>> On 7/4/19 1:29 PM, Max Reitz wrote:
>
> [...]
>
>>> Which brings me to a question: Why is the copy bitmap assigned to the
>>> target in the first place? Wouldn’t it make more sense on the source?
>>>
>>
>> *cou
On 05.07.19 18:52, John Snow wrote:
>
>
> On 7/4/19 1:29 PM, Max Reitz wrote:
[...]
>> Which brings me to a question: Why is the copy bitmap assigned to the
>> target in the first place? Wouldn’t it make more sense on the source?
>>
>
> *cough*;
>
> the idea was that the target is *most like
On 7/4/19 1:29 PM, Max Reitz wrote:
> On 03.07.19 23:55, John Snow wrote:
>> This simplifies some interface matters; namely the initialization and
>> (later) merging the manifest back into the sync_bitmap if it was
>> provided.
>>
>> Signed-off-by: John Snow
>> ---
>> block/backup.c | 76 +
On 03.07.19 23:55, John Snow wrote:
> This simplifies some interface matters; namely the initialization and
> (later) merging the manifest back into the sync_bitmap if it was
> provided.
>
> Signed-off-by: John Snow
> ---
> block/backup.c | 76 --
>
This simplifies some interface matters; namely the initialization and
(later) merging the manifest back into the sync_bitmap if it was
provided.
Signed-off-by: John Snow
---
block/backup.c | 76 --
1 file changed, 37 insertions(+), 39 deletions(-)
