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 4D1251FF0AB for ; Wed, 23 Sep 2026 12:46:35 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id C8DE021509; Wed, 23 Sep 2026 12:46:31 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 23 Sep 2026 12:46:27 +0200 Message-Id: Subject: Re: [PATCH qemu-server v1] {pbs-,vma-}restore: disable caching for LVM-thin From: "Elias Huhsovitz" To: "Markus Frank" , X-Mailer: aerc 0.20.0 References: <20260908123727.285848-1-m.frank@proxmox.com> In-Reply-To: <20260908123727.285848-1-m.frank@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1790160387277 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.608 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: DM6GI6AFFY7W4CQN2RTGQGWNPY47LAUB X-Message-ID-Hash: DM6GI6AFFY7W4CQN2RTGQGWNPY47LAUB X-MailFrom: e.huhsovitz@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: Thanks for spotting this potential optimization. Gave this quick try and results seem to be mixed. When restoring from a pbs I saw a time reduction of ~35%. When restoring locally from a .vma.zst file i saw a time increase of ~81%. see comments inline. On Tue Sep 8, 2026 at 2:37 PM CEST, Markus Frank wrote: > Mitigate performance issues with LVM-thin by disabling the page cache > when restoring to LVM-thin storage. > > This reduces the time taken for a restore to LVM-thin by approximately > half. > > A user has reported that their iSCSI LUNs cannot handle the number of > requests generated by 4k block writes when using pbs-restore with > caching enabled. I don't quite understand this. Wouldnt disabling the cache cause an increase in requests? Maybe my understanding is lacking, please clarify! A bit more detail on which specfic of setups profit from this change would also be nice IMO. > > Signed-off-by: Markus Frank > --- > src/PVE/QemuServer.pm | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm > index 149f17be..3e3d9bfb 100644 > --- a/src/PVE/QemuServer.pm > +++ b/src/PVE/QemuServer.pm > @@ -7092,7 +7092,9 @@ sub restore_proxmox_backup_archive { > # TODO: extending this needs a separate rationale, the ampli= fication > # avoided here is specific to the volblock layout > my $target_scfg =3D PVE::Storage::storage_config($storecfg, = $d->{storeid}); > - push @$pbs_restore_cmd, '--no-cache' if $target_scfg->{type}= eq 'zfspool'; > + if ($target_scfg->{type} eq 'zfspool' || $target_scfg->{type= } eq 'lvmthin') { > + push @$pbs_restore_cmd, '--no-cache'; This worked well in my testing: I restored a backup of: VM: Fedora Server 44 Disk size: 30GB Backup Location: local pbs pre-patch duration: 14s post-patch duration: 9s time REDUCTION: ~35.7% I think incorperating this makes sense, if we show performance increase for most common setups. > + } > =20 > my $dbg_cmdstring =3D PVE::Tools::cmd2string($pbs_restore_cm= d); > print "restore proxmox backup image: $dbg_cmdstring\n"; > @@ -7674,7 +7676,10 @@ sub restore_vma_archive { > =20 > # TODO: extending this needs a separate rationale, the ampli= fication > # avoided here is specific to the volblock layout > - my $cache_none =3D $scfg->{type} eq 'zfspool' ? ':cache=3Dno= ne' : ''; > + my $cache_none =3D ''; > + if ($scfg->{type} eq 'zfspool' || $scfg->{type} eq 'lvmthin'= ) { > + $cache_none =3D ':cache=3Dnone'; This decreased the performance in my testing: VM: Fedora Server 44 Disk size: 30GB Backup Location: localhost pre-patch duration: 11s post-patch duration: 20s time INCREASE: ~82% My current thesis for this is that the page cache writeback optimizations are very efficient on my CPU=20 (Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz). So without the caching, extend the I/O bottleneck. But this is just my theory, could be complete nonesense! Nevertheless, I don't belive the blanked change here is a good idea. If there are setups that benefit from this: What is your opinion on exposing this as an option for the API/UI? > + } > =20 > print $fifofh > "${map_opts}format=3D$d->{format}${cache_none}:${write_z= eros}:$d->{devname}=3D$path\n";