depends, i suppose, on ( juice > squeeze ) evaluation… but I could see ultimately adding flags to the cli / attributes to the api to request fresh/tolerate stale / tolerate stale if howStale < time… allowing for choice…
one could also imagine implementing mechanism to assert that a cached piece of information is now definitively no longer accurate… however that’d never catch all the ways the cached data becomes bad data but how deep that rabbit hole goes… is… well… i bet there’s likely a few yaks to shave somewhere in the rabbit den too… hasn’t it been said frequently that there are two really hard problems in programming? naming things , caching, and off-by-one errors? [= The contents of this message have been written, read, processed, erased, sorted, sniffed, compressed, rewritten, misspelled, overcompensated, lost, found, and most importantly delivered entirely with recycled electrons =] > On Aug 22, 2023, at 04:17, Fiona Ebner <[email protected]> wrote: > > 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 _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
