From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@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 A8CF685D97 for <pve-devel@lists.proxmox.com>; Tue, 21 Dec 2021 16:11:42 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 927D0B638 for <pve-devel@lists.proxmox.com>; Tue, 21 Dec 2021 16:11:12 +0100 (CET) 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 68285B627 for <pve-devel@lists.proxmox.com>; Tue, 21 Dec 2021 16:11:11 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 2E80A45392 for <pve-devel@lists.proxmox.com>; Tue, 21 Dec 2021 16:11:11 +0100 (CET) Message-ID: <c4276c52-cb7d-d83e-a8e7-bab7646460de@proxmox.com> Date: Tue, 21 Dec 2021 16:11:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Thunderbird/96.0 Content-Language: en-GB To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com>, Fabian Ebner <f.ebner@proxmox.com> References: <20211216121233.162288-1-f.ebner@proxmox.com> <976dac28-05b7-12cb-b534-dfdb9712db93@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <976dac28-05b7-12cb-b534-dfdb9712db93@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.066 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.012 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 Subject: Re: [pve-devel] [PATCH-SERIES storage/manager/guest-common/docs] improvements for protected backups 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: Tue, 21 Dec 2021 15:11:42 -0000 On 20/12/2021 11:31, Dominik Csapak wrote: > what do we gain by having a limit on the number of protected backups? We avoid allowing users to create an infinite number of backups. Remember that unprotected backups do not count towards the keep-X retention parameters as they are considered a specially marked snapshot outside the regular schedule, and doing so could lead to situations where no new backup can be made (if sum of keep-X == sum of protected backups), which can be pretty bad. Now, if a admin wants to limit the amount of backups a user can make of the VMs those users own, the admin sets now keep-X (which superseded max-backups) The sum of all keep-X is always the maximal, total amount of backups that can be made, but if the user marks every new backup immediately as protected they can overstep that limit arbitrarily, this series addresses that while not breaking backward comparability. > > storage 2/2 mentions that protection broke some assumption of vzdump > which is (somehow? not really explained imho) fixing it? > > if it's not fixing it, what is the relation between those things? > > also, why have a 'magic' -1 value that means indefinite, we could > simply always have that behavior? > > in my opinion, it makes no sense to limit the number of protected > backups.. see above, having the whole picture should bring sense to this.. > > if it is necessary for some reason, it would be good to include > that reason either in the commit message, or at least in the cover > letter... > I mean while the cover letter only hints it, commit message from the storage 2/2 patch is pretty clear to me.. FWIW, this was discussed quite extensively between Fabian E. and myself, and that result was further discussed with Fabian G. off-list.