From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 7C5D3714E0 for <pve-devel@lists.proxmox.com>; Wed, 18 May 2022 11:09:14 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 563FCCCB3 for <pve-devel@lists.proxmox.com>; Wed, 18 May 2022 11:09:11 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 3E01E8098 for <pve-devel@lists.proxmox.com>; Wed, 18 May 2022 11:08:33 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B6812436AA for <pve-devel@lists.proxmox.com>; Wed, 18 May 2022 11:08:31 +0200 (CEST) Message-ID: <b53f5a27-0161-dae8-21c9-ea0fb738502c@proxmox.com> Date: Wed, 18 May 2022 11:08:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: pve-devel@lists.proxmox.com, d.tschlatscher@proxmox.com References: <20220512131753.126854-1-d.tschlatscher@proxmox.com> From: Fabian Ebner <f.ebner@proxmox.com> In-Reply-To: <20220512131753.126854-1-d.tschlatscher@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.132 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -2.119 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [content.pm, storage.pm] Subject: Re: [pve-devel] [PATCH storage v2 1/2] fix #3972: Remove the .notes file when a backup is deleted X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Wed, 18 May 2022 09:09:14 -0000 Looks good to me, just a few suggestions for further improvements. Am 12.05.22 um 15:17 schrieb Daniel Tschlatscher: > When a VM or Container backup was deleted, the .notes file was not > removed, therefore, over time the dump folder would get polluted with > notes for backups that no longer existed. > As backup names contain a timestamp and as the notes cannot be reused > because of this, I think it is safe to just delete them just like we > do with the .log file. > > Furthermore, I sourced the deletion of the log and notes file into a > new function called "archive_auxiliaries_remove". This change makes it > easier to remove these files through archive_remove(), but also other > parts in the code while keeping it DRY. I like the helper. I think the second sentence above is not needed though, as that's true for most helper functions ;) > I saw this change necessary because archive_remove() does not invoke > external plugins, and doing so might have unintended side effects. > IMHO the point is that we have to keep calling vdisk_free() for PBS and external plugins in the API call. If archive_remove() were designed to call plugins, I'd argue that the side effects would be intended. Usually, the plugin knows best what to do. > Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com> > --- > PVE/API2/Storage/Content.pm | 5 ++--- > PVE/Storage.pm | 19 +++++++++++++++++-- > 2 files changed, 19 insertions(+), 5 deletions(-) > > diff --git a/PVE/API2/Storage/Content.pm b/PVE/API2/Storage/Content.pm > index 8ff858d..41b577c 100644 > --- a/PVE/API2/Storage/Content.pm > +++ b/PVE/API2/Storage/Content.pm > @@ -456,9 +456,8 @@ __PACKAGE__->register_method ({ > print "Removed volume '$volid'\n"; > if ($vtype eq 'backup' > && $path =~ /(.*\/vzdump-\w+-\d+-\d{4}_\d{2}_\d{2}-\d{2}_\d{2}_\d{2})[^\/]+$/) { > - my $logpath = "$1.log"; > - # try to cleanup our backup log file too, if still existing, #318 > - unlink($logpath) if -e $logpath; > + # Remove log file #318 and notes file #3972 if they still exist > + PVE::Storage::archive_auxiliaries_remove($path); > } > }; > > diff --git a/PVE/Storage.pm b/PVE/Storage.pm > index 72458cf..5317043 100755 > --- a/PVE/Storage.pm > +++ b/PVE/Storage.pm > @@ -1566,6 +1566,7 @@ sub archive_info { > > if ($volid =~ /^(vzdump-${type}-([1-9][0-9]{2,8})-(\d{4})_(\d{2})_(\d{2})-(\d{2})_(\d{2})_(\d{2}))\.${extension}$/) { > $info->{logfilename} = "$1.log"; > + $info->{notesfilename} = "$filename.notes"; Nit: Could use PVE::Storage::Plugin::NOTES_EXT > $info->{vmid} = int($2); > $info->{ctime} = timelocal($8, $7, $6, $5, $4 - 1, $3); > $info->{is_std_name} = 1; > @@ -1585,11 +1586,18 @@ sub archive_remove { > die "cannot remove protected archive '$archive_path'\n" > if -e protection_file_path($archive_path); > > + unlink $archive_path or die "removing archive $archive_path failed: $!\n"; Not new, but this could be improved by using unlink $archive_path or $! == ENOENT or die "..." like we do in other places. That would gracefully handle the case where two operations raced, e.g. pruning and manual removal. Previously, one of them would fail, because the file was already gone. Please make that its own patch if you go for it, thanks! > + > + archive_auxiliaries_remove($archive_path); > +} > + > +sub archive_auxiliaries_remove { > + my ($archive_path) = @_; > + > my $dirname = dirname($archive_path); > my $archive_info = eval { archive_info($archive_path) } // {}; > my $logfn = $archive_info->{logfilename}; > - > - unlink $archive_path or die "removing archive $archive_path failed: $!\n"; > + my $notesfn = $archive_info->{notesfilename}; > Style nit: The rest could be turned into a loop to avoid code repetition like: for my $type (qw(log notes)) { my $fn = $archive_info->{"${type}filename"} or next; my $path = ... > if (defined($logfn)) { > my $logpath = "$dirname/$logfn"; > @@ -1597,6 +1605,13 @@ sub archive_remove { > unlink $logpath or warn "removing log file $logpath failed: $!\n"; Same here with ENOENT > } > } > + > + if (defined($notesfn)) { > + my $notespath = "$dirname/$notesfn"; > + if (-e $notespath) { > + unlink $notespath or warn "removing notes file $notespath failed: $!\n"; and here. > + } > + } > } > > sub extract_vzdump_config_tar {