From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id A69B81FF0A5 for ; Fri, 04 Sep 2026 12:11:27 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 65D692158F; Fri, 04 Sep 2026 12:11:24 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 04 Sep 2026 12:11:19 +0200 Message-Id: Subject: Re: [RFC pve-container 1/1] mountpoint backup: allow changing backup flag at runtime From: "Thomas Ellmenreich" To: "Filip Schauer" , X-Mailer: aerc 0.20.0 References: <20260827122655.158754-1-t.ellmenreich@proxmox.com> <26b4609b-3645-4087-bb98-4eda32a7d177@proxmox.com> In-Reply-To: <26b4609b-3645-4087-bb98-4eda32a7d177@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788516675539 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.658 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: D4BJGED7CYE7HAWMHIUPPKLTNUFSFBVK X-Message-ID-Hash: D4BJGED7CYE7HAWMHIUPPKLTNUFSFBVK X-MailFrom: t.ellmenreich@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 Mon Aug 31, 2026 at 12:36 PM CEST, Filip Schauer wrote: [snip] >> +# Checks whether the changed properties can be applied at runtime. It o= nly >> +# returns true if all changes can be applied in this way. If even one >> +# property cannot be applied, returns false to ensure changes are appli= ed >> +# as a unit. >> +my $mountpoint_config_fast_plug_safe =3D sub { >> + my ($new, $old) =3D @_; >> + my @fast_plug_safe_keys =3D ("backup"); >> + >> + for my $key (uniq(keys %$new, keys %$old)) { >> + next if first { $_ eq $key } @fast_plug_safe_keys; >> + return 0 if ($new->{$key} // '') ne ($old->{$key} // ''); > > From testing I noticed that when toggling `backup` on a mount point > specifying a custom `idmap`, the `backup` property is still marked as > pending. > The reason seems to be that this is comparing array references. Even if > the arrays both hold the same data, the references still differ. Ack, thanks for this, stupid mistake. > >> + } >> + >> + 1; >> +}; >> + >> sub apply_pending_mountpoint { >> my ($class, $vmid, $conf, $opt, $storecfg, $running) =3D @_; >> =20 >> my $mp =3D $class->parse_volume($opt, $conf->{pending}->{$opt}); >> my $old =3D $conf->{$opt}; >> + >> + if (exists($conf->{$opt}) && $running) { >> + if ($mountpoint_config_fast_plug_safe->($mp, $class->parse_volu= me($opt, $old))) { >> + return; >> + } >> + die "skip\n"; # don't try to hotplug over existing mp > > Doesn't this make the later `die "skip\n" if $running && defined($old);` > unreachable? Good catch, yes. I think it will be unreachable, although I'm not sure what= to do with the open #TODO, especially since I don't quite understand what the exact meaning of "changing" is in this context. ```perl if ($mp->{type} eq 'volume' && $mp->{volume} =3D~ $PVE::LXC::NEW_DISK_RE) { # more code } else { die "skip\n" if $running && defined($old); # TODO: "changing" mount poi= nts? # more code } ``` [snip]