From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 8231D1FF0A7 for ; Wed, 19 Aug 2026 12:44:07 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 09C0D2143E; Wed, 19 Aug 2026 12:44:05 +0200 (CEST) Message-ID: <95659db5-b0ab-43dc-b9f9-50d323d0c15b@proxmox.com> Date: Wed, 19 Aug 2026 12:43:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH pve-qemu qemu-server 0/3] bypass host page cache for restore on zvol To: Fiona Ebner , pve-devel@lists.proxmox.com References: <20260818075050.86065-1-c.ebner@proxmox.com> <068ea5ee-c91e-4032-b2d3-ad6354e2e85e@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: <068ea5ee-c91e-4032-b2d3-ad6354e2e85e@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1787136215336 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.809 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: NIEADFPHWCKVMOR7IEO7LEMTFQ4ILQ62 X-Message-ID-Hash: NIEADFPHWCKVMOR7IEO7LEMTFQ4ILQ62 X-MailFrom: c.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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!