On 16.01.21 22:46, Vladimir Sementsov-Ogievskiy wrote:
I applied my series onto yours 129-fixing and found, that 129 fails for backup.
And setting small max-chunk and even max-workers to 1 doesn't help! (setting
speed like in v3 still helps).
And I found, that the problem is that really, the whole backup job goes during
drain, because in new architecture we do just job_yield() during the whole
OK, so as it was in v3, the job was drained, but since it was already yielding
while block-copy was running in the background, nothing happened; the
block-copy completed and only then was the job woken (and then there was no
reason to pause, because it was done already).
So now the job is entered on drain, too (not only user pauses), which means
that it gets a chance to pause background requests.
In backup’s case, that means invoking job_yield() again, which sets a
job_pause_point(), which will cancel the block-copy. Once the job is unpaused
(re-entered by job_resume()), backup sees block-copy is cancelled (and
finished), leaves the loop, and retries with a new block-copy call.
I think I got it now.
So all that’s left is issuing a thanks to you – thanks! – and announcing that
I’ve applied this series to my block branch (with s/not unsupported/not
supported/ in patch 23):