On 09/29/2016 07:33 AM, Kevin Wolf wrote:
Am 28.09.2016 um 14:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
I think jobs will need to remain "one coroutine, one job" for now,
but there's no reason why drive-backup or blockdev-backup can't
just create multiple jobs each if that's what they
On Thu, Sep 29, 2016 at 01:33:07PM +0200, Kevin Wolf wrote:
> Am 28.09.2016 um 14:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > >I think jobs will need to remain "one coroutine, one job" for now,
> > >but there's no reason why drive-backup or blockdev-backup can't
> > >just create multiple
Am 28.09.2016 um 14:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >I think jobs will need to remain "one coroutine, one job" for now,
> >but there's no reason why drive-backup or blockdev-backup can't
> >just create multiple jobs each if that's what they need to do.
> >(The backup job object
Ok, let's discuss it on list.
On 27.09.2016 19:19, John Snow wrote:
Replying off-list to follow your lead, but this might be a good
discussion to have upstream where Stefan and Jeff can see it.
On 09/26/2016 11:53 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi John!
What about this series? If
I should also clarify that this is ambiguously for either 2.7 or 2.8.
2.7: This fixes a real, observable problem with transactional completion
that has the capacity to hang QEMU or segfault due to QLIST corruption.
2.8: Incremental backup is not earnestly a supported feature yet as
There are a few problems with transactional job completion right now.
First, if jobs complete so quickly they complete before remaining jobs
get a chance to join the transaction, the completion mode can leave well
known state and the QLIST can get corrupted and the transactional jobs
can complete