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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 3A33EBA2CC for ; Tue, 19 Mar 2024 13:50:01 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 19BCE1EFE9 for ; Tue, 19 Mar 2024 13:49:31 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 19 Mar 2024 13:49:30 +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 D3FBE468B3 for ; Tue, 19 Mar 2024 13:49:29 +0100 (CET) Date: Tue, 19 Mar 2024 13:49:29 +0100 (CET) From: =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= To: Christian Ebner , Proxmox Backup Server development discussion Message-ID: <582353512.13251.1710852569100@webmail.proxmox.com> In-Reply-To: References: <20240305092703.126906-1-c.ebner@proxmox.com> <20240305092703.126906-28-c.ebner@proxmox.com> <1710237573.g7a8c3ms4l.astroid@yuna.none> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev59 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.065 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment 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 - Subject: Re: [pbs-devel] [RFC v2 proxmox-backup 27/36] client: implement prepare reference method 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: Tue, 19 Mar 2024 12:50:01 -0000 > Christian Ebner hat am 19.03.2024 12:51 CET geschri= eben: > On 3/12/24 11:07, Fabian Gr=C3=BCnbichler wrote: > > for these two, it might make sense to differentiate between: > > - previous manifest doesn't have that index -> no need to try download, > > we can just skip > > - previous manifest has that index -> we try to download -> we need to > > handle the error (and tell the user about the error message - it mig= ht > > indicate a problem after all!) >=20 > I think opting for the fallback to regular encoding should be fine here,= =20 > as I could not find a straight forward way to differentiate between the= =20 > two cases. Or did I miss something? >=20 > Not sure the current backup should fail because the previous one is not= =20 > fine. you misunderstood what I meant. instead of attempting to download the previ= ous index, we could first check whether it even exists. if it doesn't exist= , than we can skip the download, just log an info value, and continue witho= ut a reference. if it does (should) exist, and we attempt to download it, b= ut the download fails - then we at least want to print a different message,= or potentially fail the backup. e.g., this is how the regular incremental backup part of the code handles t= his: Previous manifest does not contain an archive called 'mail2.pxar.meta.didx'= , skipping download.. we used to always try to download and always print an error there if that d= ownload failed, which was confusing for host backups when the user added an= archive or renamed one (scary message for no reason). there the only downs= ide when a previous index cannot be downloaded is that the chunks have to b= e re-uploaded, there is no difference in the resulting archives.=20 in the new code here we have a different variant - we always try to downloa= d (unnecessary!), but always treat a failure as benign (not sure about that= part - it actually makes a difference content-wise, but also possibly spee= d/load wise ;)). also we now download the meta index twice I guess (if it exists). last, but not least - there is no actual "fallback to regular encoding" (or= at least, I think this would confuse users, for whom "regular encoding" mi= ght mean v1 archive, not "v2 archive but no re-use via metadata caching").