From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Samuel Rufinatscha <s.rufinatscha@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup v5 3/4] partial fix #6049: datastore: use config fast-path in Drop
Date: Fri, 28 Nov 2025 11:46:37 +0100 [thread overview]
Message-ID: <1764326335.8te8m3exjw.astroid@yuna.none> (raw)
In-Reply-To: <a5867e40-676c-4c72-8942-05d8576128e1@proxmox.com>
On November 28, 2025 10:03 am, Samuel Rufinatscha wrote:
> On 11/26/25 4:15 PM, Fabian Grünbichler wrote:
>> On November 24, 2025 6:04 pm, Samuel Rufinatscha wrote:
>>> @@ -307,12 +332,12 @@ impl DatastoreThreadSettings {
>>> /// - If the cached generation matches the current generation, the
>>> /// cached config is returned.
>>> /// - Otherwise the config is re-read from disk. If `update_cache` is
>>> -/// `true`, the new config and current generation are stored in the
>>> +/// `true`, the new config and bumped generation are stored in the
>>> /// cache. Callers that set `update_cache = true` must hold the
>>> /// datastore config lock to avoid racing with concurrent config
>>> /// changes.
>>> /// - If `update_cache` is `false`, the freshly read config is returned
>>> -/// but the cache is left unchanged.
>>> +/// but the cache and generation are left unchanged.
>>> ///
>>> /// If `ConfigVersionCache` is not available, the config is always read
>>> /// from disk and `None` is returned as the generation.
>>> @@ -333,14 +358,23 @@ fn datastore_section_config_cached(
>>
>> does this part here make any sense in this patch?
>>
>> we don't check the generation in the Drop handler anyway, so it will get
>> the latest cached version, no matter what?
>>
>
> we don't check the generation in the Drop handler, but the drop handler
> depends on this to potentially get a most fresh cached version?
datastore_section_config_cached will only reload the config if it was
changed over our API and the generation in the cached entry does no
longer match the current generation number. in that case there is no
need to bump the generation number, since that was already done by
whichever call saved the config and caused the generation number
mismatch in the first place - this already invalidated all previously
cached entries..
bumping the generation number only makes sense once we introduce the
force-reload mechanism in patch #4.
>
>> we'd only end up in this part of the code via lookup_datastore, and only
>> if:
>> - the previous cached entry and the current one have a different
>> generation -> no need to bump again, the cache is already invalidated
>> - there is no previous cached entry -> nothing to invalidate
>>
>> I think this part should move to the next patch..
>
> Shouldn't it be rather in PATCH 2 then, instead part of the TTL feature
> Also I would adjust the comment below then, so that it doesn't
> necessarily just benefit the drop handler that calls
> datastore_section_config_cached(false) but would in general future uses
> of datastore_section_config_cached(false)?
it has no benefit at this point in the series (or after/at patch #2),
see above. bumping only makes sense if we detect the generation number
is not valid, which we can only do via the digest check from patch#4.
and the digest check only makes sense with the TTL force-reload, because
else we can never end up in the code path where we read the config
without the cache already being invalid anyway.
>
>>
>>> let (config_raw, _digest) = pbs_config::datastore::config()?;
>>> let config = Arc::new(config_raw);
>>>
>>> + let mut effective_gen = current_gen;
>>> if update_cache {
>>> + // Bump the generation. This ensures that Drop
>>> + // handlers will detect that a newer config exists
>>> + // and will not rely on a stale cached entry for
>>> + // maintenance mandate.
>>> + let prev_gen = version_cache.increase_datastore_generation();
>>> + effective_gen = prev_gen + 1;
>>> +
>>> + // Persist
>>> *config_cache = Some(DatastoreConfigCache {
>>> config: config.clone(),
>>> - last_generation: current_gen,
>>> + last_generation: effective_gen,
>>> });
>>> }
>>>
>>> - Ok((config, Some(current_gen)))
>>> + Ok((config, Some(effective_gen)))
>>> } else {
>>> // Fallback path, no config version cache: read datastore.cfg and return None as generation
>>> *config_cache = None;
>>> --
>>> 2.47.3
>>>
>>>
>>>
>>> _______________________________________________
>>> pbs-devel mailing list
>>> pbs-devel@lists.proxmox.com
>>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>>>
>>
>>
>> _______________________________________________
>> pbs-devel mailing list
>> pbs-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>
>
>
_______________________________________________
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:[~2025-11-28 10:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-24 17:04 [pbs-devel] [PATCH proxmox-backup v5 0/4] datastore: remove config reload on hot path Samuel Rufinatscha
2025-11-24 17:04 ` [pbs-devel] [PATCH proxmox-backup v5 1/4] partial fix #6049: config: enable config version cache for datastore Samuel Rufinatscha
2025-11-26 15:15 ` Fabian Grünbichler
2025-11-24 17:04 ` [pbs-devel] [PATCH proxmox-backup v5 2/4] partial fix #6049: datastore: impl ConfigVersionCache fast path for lookups Samuel Rufinatscha
2025-11-26 15:15 ` Fabian Grünbichler
2025-11-26 17:21 ` Samuel Rufinatscha
2025-11-24 17:04 ` [pbs-devel] [PATCH proxmox-backup v5 3/4] partial fix #6049: datastore: use config fast-path in Drop Samuel Rufinatscha
2025-11-26 15:15 ` Fabian Grünbichler
2025-11-28 9:03 ` Samuel Rufinatscha
2025-11-28 10:46 ` Fabian Grünbichler [this message]
2025-11-28 11:10 ` Samuel Rufinatscha
2025-11-24 17:04 ` [pbs-devel] [PATCH proxmox-backup v5 4/4] partial fix #6049: datastore: add TTL fallback to catch manual config edits Samuel Rufinatscha
2025-11-26 15:15 ` Fabian Grünbichler
2025-11-26 15:16 ` [pbs-devel] [PATCH proxmox-backup v5 0/4] datastore: remove config reload on hot path Fabian Grünbichler
2025-11-26 16:10 ` Samuel Rufinatscha
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=1764326335.8te8m3exjw.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=s.rufinatscha@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.