From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 8DC4F1FF16B for ; Fri, 13 Sep 2024 15:51:34 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D6DBA140F6; Fri, 13 Sep 2024 15:51:35 +0200 (CEST) From: Maximiliano Sandoval To: Fiona Ebner In-Reply-To: <49fb5ba5-02df-4ff6-8928-3d9376d0f532@proxmox.com> (Fiona Ebner's message of "Tue, 10 Sep 2024 15:13:39 +0200") References: <20240709115116.333708-1-m.sandoval@proxmox.com> <49fb5ba5-02df-4ff6-8928-3d9376d0f532@proxmox.com> Date: Fri, 13 Sep 2024 15:51:32 +0200 Message-ID: MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.299 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [btrfsplugin.pm] URI_NOVOWEL 0.5 URI hostname has long non-vowel sequence Subject: Re: [pve-devel] [PATCH storage 1/2] fix #3873: btrfs: check for correct subvolume taking snapshot X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Cc: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Fiona Ebner writes: > Am 09.07.24 um 13:51 schrieb Maximiliano Sandoval: >> Suppose we are doing a snapshot of disk 0 for VM 100. The >> dir_glob_foreach runs over $path=/subvolume/images/100, lists all >> snapshot names and appends their names to the path of the disk, e.g. >> /subvolume/images/vm-100-disk-0@SNAP_NAME, but the original directory >> $path might contain a second disk `vm-100-disk-1` which is also listed >> by the dir_glib_foreach. >> >> The patch skips images which reference other disks. >> >> Signed-off-by: Maximiliano Sandoval >> --- >> src/PVE/Storage/BTRFSPlugin.pm | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/src/PVE/Storage/BTRFSPlugin.pm b/src/PVE/Storage/BTRFSPlugin.pm >> index 42815cb..dc0420d 100644 >> --- a/src/PVE/Storage/BTRFSPlugin.pm >> +++ b/src/PVE/Storage/BTRFSPlugin.pm >> @@ -767,6 +767,9 @@ sub volume_export { >> push @$cmd, (map { "$path\@$_" } ($with_snapshots // [])->@*), $path; >> } else { >> dir_glob_foreach(dirname($path), $BTRFS_VOL_REGEX, sub { > > I feel like this would be a bit nicer (and slightly more robust) if it > used foreach_subvol() and would check the basename like done in > free_image(). Or even better, introduce a new helper that iterates over > all snapshots of a specific volume to not repeat ourselves here and in > free_image(). Since foreach_subvol() is only used once (i.e. in > free_image()), we could even replace that. There's another pre-existing > thing that's a bit confusing, which is that BTRFS_VOL_REGEX only matches > snapshot volumes and not the actual volume itself AFAICS. Agreed, I will submit a patch improving the situation (mostly for readability reasons) once I am back from vacations. Imho this could be merged as-is as this is rather self-contained and already tested. -- Maximiliano _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel