Am 21.02.2023 um 11:57 hat Fiona Ebner geschrieben:
> Am 14.02.23 um 17:19 schrieb Vladimir Sementsov-Ogievskiy:
> > On 02.02.23 16:27, Fiona Ebner wrote:
> >> Am 02.02.23 um 12:34 schrieb Kevin Wolf:
> >>> But having to switch the mirror job to sync mode just to avoid doing I/O
> >>> on an
Am 14.02.23 um 17:19 schrieb Vladimir Sementsov-Ogievskiy:
> On 02.02.23 16:27, Fiona Ebner wrote:
>> Am 02.02.23 um 12:34 schrieb Kevin Wolf:
>>> But having to switch the mirror job to sync mode just to avoid doing I/O
>>> on an inactive device sounds wrong to me. It doesn't fix the root cause
On 14.02.23 17:29, Fiona Ebner wrote:
[..]
[0]: Is there a good way to peek the iterator without doing something
like the following (we do know the offset from last time in
mirror_iteration(), so that is not an issue)?
offset_from_last_time = bdrv_dirty_iter_next(s->dbi);
...other stuff...
On 02.02.23 16:27, Fiona Ebner wrote:
Am 02.02.23 um 12:34 schrieb Kevin Wolf:
Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
Frankly speaking I would say that this switch could be considered
NOT QEMU job and we should just send a notification
On 02.02.23 18:23, Kevin Wolf wrote:
Am 02.02.2023 um 14:35 hat Denis V. Lunev geschrieben:
On 2/2/23 14:27, Fiona Ebner wrote:
Am 02.02.23 um 12:34 schrieb Kevin Wolf:
Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
Frankly speaking I would
Am 02.02.23 um 12:34 schrieb Kevin Wolf:
> Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
>> Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
>>> Frankly speaking I would say that this switch could be considered
>>> NOT QEMU job and we should just send a notification (event) for the
>>>
Am 02.02.23 um 12:09 schrieb Denis V. Lunev:
> On 2/2/23 11:19, Fiona Ebner wrote:
>> Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
>>> Frankly speaking I do not like this. I'd better would not
>>> rely on the enable/disable of the whole bitmap but encode
>>> mode into MirrorOp and mark blocks
Am 02.02.2023 um 14:35 hat Denis V. Lunev geschrieben:
> On 2/2/23 14:27, Fiona Ebner wrote:
> > Am 02.02.23 um 12:34 schrieb Kevin Wolf:
> > > Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
> > > > Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
> > > > > Frankly speaking I would say that this
On 2/2/23 14:27, Fiona Ebner wrote:
Am 02.02.23 um 12:34 schrieb Kevin Wolf:
Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
Frankly speaking I would say that this switch could be considered
NOT QEMU job and we should just send a notification
Am 02.02.23 um 12:34 schrieb Kevin Wolf:
> Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
>> Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
>>> Frankly speaking I would say that this switch could be considered
>>> NOT QEMU job and we should just send a notification (event) for the
>>>
Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
> Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
> > Frankly speaking I would say that this switch could be considered
> > NOT QEMU job and we should just send a notification (event) for the
> > completion of the each iteration and management
On 2/2/23 11:19, Fiona Ebner wrote:
Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
On 1/31/23 18:44, Vladimir Sementsov-Ogievskiy wrote:
+ Den
Den, I remember we thought about that, and probably had a solution?
Another possible approach to get benefits from both modes is to switch
to blocking
Am 31.01.23 um 18:44 schrieb Vladimir Sementsov-Ogievskiy:
>> @@ -1035,10 +1036,31 @@ static int coroutine_fn mirror_run(Job *job,
>> Error **errp)
>> if (s->in_flight == 0 && cnt == 0) {
>> trace_mirror_before_flush(s);
>> if (!job_is_ready(>common.job)) {
>>
Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
> On 1/31/23 18:44, Vladimir Sementsov-Ogievskiy wrote:
>> + Den
>>
>> Den, I remember we thought about that, and probably had a solution?
>>
>> Another possible approach to get benefits from both modes is to switch
>> to blocking mode after first loop
On 1/31/23 18:44, Vladimir Sementsov-Ogievskiy wrote:
+ Den
Den, I remember we thought about that, and probably had a solution?
Another possible approach to get benefits from both modes is to switch
to blocking mode after first loop of copying. [*]
Hmm. Thinking about proposed solution it
+ Den
Den, I remember we thought about that, and probably had a solution?
Another possible approach to get benefits from both modes is to switch to
blocking mode after first loop of copying. [*]
Hmm. Thinking about proposed solution it seems, that [*] is better. The main reason of
Am 07.12.22 um 14:27 schrieb Fiona Ebner:
> The new copy mode starts out in 'background' mode and switches to
> 'write-blocking' mode once the job transitions to ready.
>
> Before switching to active mode and indicating that the drives are
> actively synced, it is necessary to have seen and
The new copy mode starts out in 'background' mode and switches to
'write-blocking' mode once the job transitions to ready.
Before switching to active mode and indicating that the drives are
actively synced, it is necessary to have seen and handled all guest
I/O. This is done by checking the dirty
18 matches
Mail list logo
