From: Christian Ebner <c.ebner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup 2/2] datastore: reinsert unused chunks into cache during instantiation
Date: Tue, 5 Aug 2025 08:15:55 +0200 [thread overview]
Message-ID: <5c48ab39-24b4-4b40-8f2c-9e5cc9c257c3@proxmox.com> (raw)
In-Reply-To: <c9516bbd-9853-4556-b42e-872be35bd470@proxmox.com>
On 8/4/25 10:41 PM, Thomas Lamprecht wrote:
> Am 01.08.25 um 16:10 schrieb Christian Ebner:
>> The local datastore chunk cache stores the currently cached chunk
>> digests in-memory, the chunk's data is stored however on the
>> filesystem. The in-memory cache might however be lost when:
>> - the datastore is removed for the lookup cache when a corresponding
>> maintenance mode is set.
>> - the services are restarted.
>> - the system is rebooted.
>>
>> After above actions, the cache is reistantiated again together with
>> the datastore on the next datastore lookup, calculating a cache
>> capacity based on the currently available storage space. This however
>> leaves the previously cached chunks out.
>> Therefore, reinsert them in an asynchronos task, by iterating over
>> them an insert the chunk digest again. For these previously used
>> chunks, increase also the cache size as this is now usable storage
>> for the cache as well.
>
> I really would like some basic numbers for patches doing things with
> caches, especially if they iterate over all chunks present on disk, IIUC.
> AFAICIT it at least happens in the background, so doesn't delays the
> one instantiating the new datastore struct directly, but without some
> pacing going through all chunks as fast as possible might introduce
> significant IO pressure I think.
Yes, although given that the cache should be limited in most cases, the
actual chunk iteration should not be that bad. It took a couple of
seconds with a cache store containing 8190 chunks, although on a NVME
SSD. But I will do a more in depth runtime and I/O pressure analysis in
the next days.
> Also, what happens if the datastore instance is already dropped again
> during this cache re-warming? AFAICT that can only realistically happen
> with maintenance mode, as with restarts/reboots it naturally should not
> matter. Also, just to be sure, this might also block any shutdown
> future from resolving, just like any other spawn_blocking, or am I
> mistaken?
Right, these are edge case I did not consider, given that these patches
were created rather in a hurry with the primary intention to have a stop
gap. After all the users will run out of storage space sooner or later,
given that nothing will ever reclaim the space occupied by the chunks
not in the cache anymore.
For now a
```
find /<datastore-path>/.chunks/ -type f -exec truncate --size 0 {} \;
```
while having the datastore in maintenance mode offline is a valid
workaround to recover from these cases, although clearing the contents
instead of reclaiming them.
But all in all, given your concerns I will invest more time into these
patches so we can (hopefully) roll them out and fix this issue for the
users.
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
prev parent reply other threads:[~2025-08-05 6:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-01 14:10 [pbs-devel] [PATCH proxmox-backup 0/2] rewarm local datastore chunk cache on datastore instantiation Christian Ebner
2025-08-01 14:10 ` [pbs-devel] [PATCH proxmox-backup 1/2] tools: lru cache: allow to dynamically increase the cache capacity Christian Ebner
2025-08-01 14:10 ` [pbs-devel] [PATCH proxmox-backup 2/2] datastore: reinsert unused chunks into cache during instantiation Christian Ebner
2025-08-04 20:42 ` Thomas Lamprecht
2025-08-05 6:15 ` Christian Ebner [this message]
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=5c48ab39-24b4-4b40-8f2c-9e5cc9c257c3@proxmox.com \
--to=c.ebner@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=t.lamprecht@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.