[pve-devel] [PATCH v4 manager 7/7] Always use prune-backups instead of maxfiles internally

Fabian Ebner f.ebner at proxmox.com
Mon Aug 24 09:25:48 CEST 2020


Am 21.08.20 um 13:33 schrieb Thomas Lamprecht:
> On 09.07.20 14:45, Fabian Ebner wrote:
>> For the use case with '--dumpdir', it's not possible to call prune_backups
>> directly, so a little bit of special handling is required there.
>>
>> Signed-off-by: Fabian Ebner <f.ebner at proxmox.com>
>> ---
>>   PVE/VZDump.pm | 42 ++++++++++++++++--------------------------
>>   1 file changed, 16 insertions(+), 26 deletions(-)
>>
> 
> breaks having a max backup set on a storage, before this it complains, after
> this I can make as many backups I want..
> 

Sorry, turns out it was a typo:

Am 09.07.20 um 14:45 schrieb Fabian Ebner:
 > diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
 > index 17153fe4..d87ef857 100644
 > --- a/PVE/VZDump.pm
 > +++ b/PVE/VZDump.pm
 > @@ -484,8 +484,10 @@ sub new {
 >   	die "internal error";
 >       }
 >
 > -    if (!defined($opts->{'prune-backups'}) && 
!defined($opts->{maxfiles})) {
 > -	$opts->{maxfiles} = $defaults->{maxfiles};
 > +    if (!defined($opts->{'prune-backups'})) {
 > +	$opts->{maxfiles} //= $defaults->{maxfiles};
 > +	$opts->{'prune_backups'} = { 'keep-last' => $opts->{maxfiles} };

With 'prune-backups' here, it should work. Should I send a v5?

 > +	delete $opts->{maxfiles};
 >       }





More information about the pve-devel mailing list