[pve-devel] [RFC storage/proxmox{, -perl-rs} 0/7] cache storage plugin status for pvestatd/API status update calls
Wolfgang Bumiller
w.bumiller at proxmox.com
Tue Aug 22 13:25:21 CEST 2023
On Tue, Aug 22, 2023 at 11:17:14AM +0200, Fiona Ebner wrote:
> Am 21.08.23 um 15:44 schrieb Lukas Wagner:
> > Open questions:
> > - not sure what a good expiration time for cached entries is. For
> > now I picked 30s, but there was not much thought behind that value.
> >
>
> If operations affecting the values like allocation, resize, etc. would
> invalidate the cache, I think we could go for a bit more. But if they
> don't, the limit can't be too high IMHO. Otherwise, users will wonder
> why the usage on the storage doesn't change after their action.
>
> And would it make sense to have the cache be opt-in? So that only
> pvestatd would use it, but standalone API/CLI calls always get current
> values? If there is invalidation like mentioned above, that might not be
> needed, but otherwise, I'm a bit afraid that handing out (slightly)
> outdated values might trip up some automated scripts doing batch work or
> something.
CLI tools should definitely have an explicit cache-opt-out switch (or -
for some of them - that might even be a sensible default, but ideally
you'd also have a way to quickly check for temporary discrepancies
between the cache and the current value via the CLI).
But I the API should stick to to using the cache by default. (But can of
course also have an explicit cache-opt-out or force-cache-refresh option
- whichever makes more sense.)
That's kind of the whole idea, to not have 5 daemons query the exact
same data simultaneously ;-)
More information about the pve-devel
mailing list