From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id C825D1FF136 for ; Mon, 26 Jan 2026 15:02:30 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2ABEAF08C; Mon, 26 Jan 2026 15:02:53 +0100 (CET) Message-ID: <02bfc738-fb21-4d14-a982-67cb42b5690e@proxmox.com> Date: Mon, 26 Jan 2026 15:02:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Robert Obkircher , Proxmox Backup Server development discussion References: <20260123154147.222215-1-r.obkircher@proxmox.com> <20260123154147.222215-10-r.obkircher@proxmox.com> <767de04e-3f23-4cf3-8ad8-45d4c2d4013f@proxmox.com> <5aea0de2-2cc1-4c30-a609-2cdb1a2497a6@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: <5aea0de2-2cc1-4c30-a609-2cdb1a2497a6@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1769436105904 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.048 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 Subject: Re: [pbs-devel] [PATCH v4 proxmox-backup 09/11] datastore: use u64 instead of usize for fidx writer content size 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 1/26/26 2:19 PM, Robert Obkircher wrote: > > On 1/26/26 12:38, Christian Ebner wrote: >> Not sure about these changes, maybe other devs have a stronger >> opinion on this one. >> >> If we do want to adapt this, then IMHO this should however be done >> throughout the whole codebase, for the dynamic index as well. > The dynamic reader/writer and the FixedIndexReader already use u64 for > content > size and offsets. The API only supports 4 MiB chunks anyway, so it > shouldn't matter > if we keep using u32 there. Disregard that comment with respect to the dynamic index in that case, seems indeed to be the case and I got sidetracked by the index positions which are usize. But still this would be nice to have consistent, e.g. there is the check for chunk size used on the client side [0]. [0] https://git.proxmox.com/?p=proxmox-backup.git;a=blob;f=pbs-datastore/src/chunk_store.rs;h=bd1dc353b5e8f5f0e7b8f2d6788f4d29433e2a9e;hb=HEAD#l42 _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel