Re: [PATCH qemu-server v1] {pbs-,vma-}restore: disable caching for LVM-thin

["Elias Huhsovitz" <e.huhsovitz@proxmox.com>]

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 <m.frank@proxmox.com>
> ---
>  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 amplification
>              # avoided here is specific to the volblock layout
>              my $target_scfg = 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.

> +            }
>  
>              my $dbg_cmdstring = PVE::Tools::cmd2string($pbs_restore_cmd);
>              print "restore proxmox backup image: $dbg_cmdstring\n";
> @@ -7674,7 +7676,10 @@ sub restore_vma_archive {
>  
>              # TODO: extending this needs a separate rationale, the amplification
>              # avoided here is specific to the volblock layout
> -            my $cache_none = $scfg->{type} eq 'zfspool' ? ':cache=none' : '';
> +            my $cache_none = '';
> +            if ($scfg->{type} eq 'zfspool' || $scfg->{type} eq 'lvmthin') {
> +                $cache_none = ':cache=none';

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 
(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?

> +            }
>  
>              print $fifofh
>                  "${map_opts}format=$d->{format}${cache_none}:${write_zeros}:$d->{devname}=$path\n";