Recent QEMU changes around preallocate_set_perm mandates that it is not possible to poll on aio_context inside this function anymore. Thus truncate operation has been moved inside bottom half. This bottom half is scheduled from preallocate_set_perm() and that is all.
This approach proven to be problematic in a lot of places once additional operations are executed over preallocate filter in production. The code validates that permissions have been really changed just after the call to the set operation. A lot of time has been spent since the previous series in order to stabilize changes with a whole product regression. This is reflected with some unit tests added. Without this series 2 out of 3 are broken. In general, the approach has been changed. We should not have image truncate inside permission handling routines. That would be quite incorrect and wrong, f.e. we potentially have truncate() executed once we returned from bdrv_inactivate() and the ownership of the image does not belong to us anymore. It should be noted that the life cycle of the image length is quite similar to one of the CBT and thus places where CBT is handled should provide a good hint. This is just a guideline note. Thus the most noticeable change is an addition of preallocate_inactivate() callback and cleanup of all asynchronous stuff. Changes from v2: - the series has been completely rethinked Signed-off-by: Denis V. Lunev <d...@openvz.org> CC: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru> CC: Andrey Drobyshev <andrey.drobys...@virtuozzo.com> CC: Kevin Wolf <kw...@redhat.com> CC: Hanna Reitz <hre...@redhat.com>
