From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id D2AFD1FF168 for ; Tue, 26 Nov 2024 08:29:11 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 36A5128B5D; Tue, 26 Nov 2024 08:29:11 +0100 (CET) Message-ID: <2f6448ed-e19d-4031-9636-2424c1e1bb75@proxmox.com> Date: Tue, 26 Nov 2024 08:29:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox Backup Server development discussion References: <20241118092435.81880-1-c.ebner@proxmox.com> <20241118092435.81880-2-c.ebner@proxmox.com> <5e5a54b1-3d33-402f-8033-089e63590b43@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: <5e5a54b1-3d33-402f-8033-089e63590b43@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.031 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pbs-devel] [PATCH docs 1/3] docs: explain the working principle of the change detection modes 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: , Reply-To: Proxmox Backup Server development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On 11/25/24 22:09, Thomas Lamprecht wrote: > Am 18.11.24 um 10:24 schrieb Christian Ebner: >> Describe in more details how the different change detection modes >> operate and give insights into the inner workings, especially for the >> more complex `metadata` mode, which involves lookahead caching and >> padding calculation for reused payload chunks. >> >> Suggested-by: Dietmar Maurer >> Signed-off-by: Christian Ebner > > it would be additionally good to describe why mtime, not ctime and when > metadata detection can fail (if user/tools do bad things). Agreed, will add more details on this as well. > > And for the overview it would be great to note why a data mode exists, as > there can be some confusions from users interpreting this as three different > ways to create the archive(s), not two ways to do that with two change detection > modes. > Could be also interesting to note that it works with older PBS in general beside > some archive specific features like file-browsing. > Okay, will also add a short note that since the legacy mode and the two other modes use different archive formats, they do not reuse chunks as efficiently when using mixed modes on the same datastore. > This mail is inspired a bit from the post I replied here: > > https://forum.proxmox.com/threads/proxmox-ve-8-3-released.157793/page-2#post-723212 _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel