Re: [PATCH pve-qemu qemu-server 0/3] bypass host page cache for restore on zvol

[Christian Ebner <c.ebner@proxmox.com>]

On 8/19/26 12:02 PM, Fiona Ebner wrote:
> Am 18.08.26 um 9:51 AM schrieb Christian Ebner:
>> This patch series skips writing to the host page cache for restores
>> to zvols, with the intention to avoid potential I/O delay issues for
>> other ZFS-backed VMs during page writeback on certain setups, as
>> reported in enterprise support and reproduced internally.
>>
>> This patch series adds an optional no-cache parameter for pbs-restore
>> command invocation, setting the BDRV_O_NOCACHE flag for the block
>> device being restored to and sets `cache=none` for vma restores.
>>
>> Since this seems to affect only zvol's, conditionally set the flag only
>> during restores to storages with type `zfspool`.
>>
>> pve-qemu:
>>
>> Christian Ebner (1):
>>    add optional no-cache flag to bypass host page cache on pbs-restore
>>
>>   ...no-cache-flag-to-skip-host-page-cach.patch | 64 +++++++++++++++++++
>>   debian/patches/series                         |  1 +
>>   2 files changed, 65 insertions(+)
>>   create mode 100644 debian/patches/pve/0047-pbs-restore-add-no-cache-flag-to-skip-host-page-cach.patch
>>
>> qemu-server:
>>
>> Christian Ebner (2):
>>    pbs-restore: set 'no-cache' on block devices backed by zfspool
>>    vma restore: skip page cache on block devices backed by zfspool
> 
> Didn't have time to look into it in detail, just noticed that there is
> no version guarding. I.e. downgrading QEMU will lead to broken restore
> since the old binary does not understand the new flag. We should avoid
> this. If we don't want to wait until 11.1 for this, you will need to
> check the revision of the binary, which requires extending the
> kvm_user_version() helper to catch the package name as well ;)

Ack, thanks for initial feedback, will look into this now.

> The commit messages could mention that the issue is that the cache fills
> up with no actual writes happening until then.
> 
> How does the change affect restore performance/load on other storages? I

Didn't spend time on performance and load testing for unrelated storage 
types with this enabled since this was intended as stop-gap for the I/O 
latency issues for other guests on ZFS. But will have a closer look.

> kinda feel like it might make sense to do this more broadly, but of
> course that requires actual data to support it. If the results are
> positive, please add a reminder comment to extend this to other storages
> in the future.
> 
> The general approach looks okay to me :)

Good, thanks!