On 04.12.2020 18:11, Peter Krempa wrote:
On Fri, Nov 13, 2020 at 09:53:28 +0300, Nikolay Shirokovskiy wrote:
> This is successor to [1] but I changed the subject as in the review the patch
> 'qemu: sync backing chain update in virDomainGetBlockJobInfo' was not
> considered good one from design POV. However I think the basic patch is helpful
> to address similar issues. Look at [*] for example, there it allows to sync
> backing chains during query block stats.
>
> In discussion of [1] I stated that first patch will also allow to get rid of
> stale block job events on reconnection to qemu. But this will require
> additional work actually so with this patch series stale events are still
> present. And in the discussion it was also mentioned by Peter that stale events
> are not harmful for legacy blockjobs code. I also removed previous attempts to
> eliminate some of stale events.
>
> I still keep patch for virDomainGetBlockJobInfo. May be in comparsion to [*]
> the approach the patch takes will look not so bad :)
>
> [1] First version of the patch series
>
https://www.redhat.com/archives/libvir-list/2020-October/msg01133.html
I had a look at this series and it's just doing too much just to "fix"
apps which insist on polling especially with pre-blockdev qemu. I simply
it's not worth adding the complexity you are proposing.
NACK series.
Ok. By the way what about the issue described in
[PATCH v2 09/10] qemu: fix race on legacy block completion and quering stats
Are modern blockjobs have similar?
Nikolay
Instead I propose we add a workaround which will report fake unfinished
job:
https://www.redhat.com/archives/libvir-list/2020-December/msg00352.html
The scope of this is way more limited and it doesn't actually try to
modify the job code handovers which is very dangerous.
I had a look at this series and it's just doing too much just to "fix"
apps which insist on polling especially with pre-blockdev qemu.
Additionally it adds documentation stating that apps should not poll
virDomainGetBlockJobInfo.