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 {