From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 2531C96B6A for ; Thu, 26 Jan 2023 13:44:38 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id F3B9E22CB6 for ; Thu, 26 Jan 2023 13:44:37 +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 for ; Thu, 26 Jan 2023 13:44:37 +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 1967346543 for ; Thu, 26 Jan 2023 13:44:37 +0100 (CET) Date: Thu, 26 Jan 2023 13:44:35 +0100 From: Christoph Heiss To: Thomas Lamprecht Cc: Proxmox Backup Server development discussion Message-ID: <20230126124435.xrk5bwm2jt242tk2@maui.proxmox.com> References: <20230125121902.404950-1-c.heiss@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL -0.171 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 RCVD_IN_DNSWL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block 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 Subject: Re: [pbs-devel] [RFC PATCH v2 proxmox-backup{, -qemu}, pve-{qemu, manager}, qemu-server 0/7] fix #4289: Set protected flag on backup creation X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2023 12:44:38 -0000 On Wed, Jan 25, 2023 at 05:00:03PM +0100, Thomas Lamprecht wrote: > Am 25/01/2023 um 13:18 schrieb Christoph Heiss: > > When a datastore has the "Verify New Snapshots" flag set and a backup > > with the protected flag set is created (e.g. using `vzdump --protected 1 > > ..`), the job might fail in the final stages due to a locking race. The > > "Verify New Snapshots" flag means that backups are immediately locked for > > verification as soon as their transfer is finished and the `/finish` > > endpoint is called. > > > > If vzdump then tries to set the `protected` flag on that backup, it can > > fail due to being currently locked by the verification task. > > but the protection flag resides in the "unprotected" part of the manifest, > and IMO it seems very odd that I cannot change a protection flag if verification > is running, which can happen anytime not only on verify-new. Hm, I did indeed not consider this case - this really seems a bit quirky then after all. > > So why not adapt this that protection can be changed independent of verification, > which would require zero client changes and make for a better UX in general - > albeit it certainly needs some well thought out (lock) handling. I will look into this, thanks for the hint! I tried messing with the locking before, which wasn't all that fruitfully. In any case, definitely seems like the right way for this now, plus it would make things a lot cleaner. Did not know that the protection flag was generally a "unprotected" part of the manifest, this of course changes things.