From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH v3 proxmox-backup 1/5] fix #3847: datastore: support writing fidx files of unknown size
Date: Mon, 19 Jan 2026 14:25:43 +0100 [thread overview]
Message-ID: <1768829102.ztdy63pzye.astroid@yuna.none> (raw)
In-Reply-To: <4e0c865f-9181-4ba4-a99e-4f2f5e489560@proxmox.com>
On January 19, 2026 1:54 pm, Robert Obkircher wrote:
>
> On 1/16/26 15:28, Fabian Grünbichler wrote:
>> Quoting Robert Obkircher (2026-01-16 13:42:36)
>>> On 1/14/26 14:13, Fabian Grünbichler wrote:
>>>> On January 9, 2026 6:35 pm, Robert Obkircher wrote:
[..]
>>>>> + pub fn grow_to_size(&mut self, requested_size: usize) -> Result<(), Error> {
>>>>> + if self.size < requested_size {
>>>>> + if !self.growable_size {
>>>>> + bail!("refusing to resize from {} to {requested_size}", self.size);
>>>>> + }
>>>>> + let new_len = requested_size.div_ceil(self.chunk_size);
>>>>> + if new_len * self.chunk_size != requested_size {
>>>>> + // not a full chunk, so this must be the last one
>>>>> + self.growable_size = false;
>>>>> + self.set_index_capacity_or_unmap(new_len)?;
>>>>> + } else if new_len > self.index_capacity {
>>>>> + self.set_index_capacity_or_unmap(new_len.next_power_of_two())?;
>>>>> + };
>>>>> + assert!(new_len <= self.index_capacity);
>>>>> + self.index_length = new_len;
>>>>> + self.size = requested_size;
>>>>> + }
>>>> should we handle the else part here? i.e., error out if shrinking is
>>>> requested?
>>> The else part is expected to succeed. I considered renaming the method to
>>> something like grow_if_smaller or ensure_capacity to make this clear, but
>>> I'm not quite happy with those names either.
>> we could
>> - call it resize, move the size check to the (only) call site, and allow
>> shrinking
>> - call it reserve, make it only handle capacity, and move the size update to a
>> (renamed) check_chunk_alignment
>> - combine grow_to_size and check_chunk_alignment and find a fitting name for
>> what it does :-P
>> - keep it as is, but find a better name
>
> Another option would be a single add_chunk(&mut self, offset, size, digest)
> method that does everything, so the badly named resize method can
> simply stay private.
that seems like possibly the nicest solution here..
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2026-01-19 13:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 17:35 [pbs-devel] [PATCH v3 proxmox-backup 0/5] fix: #3847 pipe from STDIN to proxmox-backup-client Robert Obkircher
2026-01-09 17:35 ` [pbs-devel] [PATCH v3 proxmox-backup 1/5] fix #3847: datastore: support writing fidx files of unknown size Robert Obkircher
2026-01-14 13:13 ` Fabian Grünbichler
2026-01-16 12:42 ` Robert Obkircher
2026-01-16 14:28 ` Fabian Grünbichler
2026-01-19 12:54 ` Robert Obkircher
2026-01-19 13:25 ` Fabian Grünbichler [this message]
2026-01-09 17:35 ` [pbs-devel] [PATCH v3 proxmox-backup 2/5] fix #3847: datastore: test FixedIndexWriter Robert Obkircher
2026-01-14 13:13 ` Fabian Grünbichler
2026-01-16 12:48 ` Robert Obkircher
2026-01-16 14:30 ` Fabian Grünbichler
2026-01-09 17:35 ` [pbs-devel] [PATCH v3 proxmox-backup 3/5] fix #3847: api: backup: make fixed index file size optional Robert Obkircher
2026-01-14 13:13 ` Fabian Grünbichler
2026-01-09 17:35 ` [pbs-devel] [PATCH v3 proxmox-backup 4/5] fix #3847: client: support fifo pipe inputs for images Robert Obkircher
2026-01-09 17:35 ` [pbs-devel] [PATCH v3 proxmox-backup 5/5] fix #3847: client: treat minus sign as stdin Robert Obkircher
2026-01-14 13:13 ` [pbs-devel] [PATCH v3 proxmox-backup 0/5] fix: #3847 pipe from STDIN to proxmox-backup-client Fabian Grünbichler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1768829102.ztdy63pzye.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.