[pbs-devel] [PATCH proxmox-backup v4 1/3] fix #4077: Estimated Full metric on ext4 file systems

[Thomas Lamprecht]

Am 10/10/2022 um 16:23 schrieb Daniel Tschlatscher:
> It seems to me, finding a way to tell which dataset to use for the
> calculation is the preferable way here, as the heuristic approach of
> recording it anyway and switching at a later date would show the same
> jump for users upgrading from an earlier version or in cases where the
> RRDB did not have enough time to populate between versions.

sure, if you don't add a dynamic check on runtime, but the one that update
are often those that update frequently or on every point release, so it
probably would cover a major part of users - albeit, that's rather
guesstimation and it's also a burden to keep track and communicate to users,
so probably better to either mix in dynamically, if new value hasn't enough
data but old value has, or just ignore it altogether; I'd at least try to do
the former, if it's a lot of complexity we can still drop it.


> Or would you reckon this is acceptable in such (less frequent) cases, as
> it is more of a cosmetic feature anyway?

certainly no deal breaker, not sure how much its actually used, or relied
on in practice anyway.

> Mostly, it made it easier to just drop in place instead of the value for
> total, rather than querying combining the data for used and available. I
> didn't overwrite it also, as that would be a breaking change.
> 
> In my eyes, it is also more easily understandable from the POV of an API
> user because the naming for available does not inherently carry the
> information that this value excludes any unusable storage for
> unprivileged users.
> I see potential for confusion here, as one might incorrectly assume that
> used + available = total, when that is, in my testing, really never the
> case. Potentially, because of reserved blocks on ext4 file systems and
> because of a small amount which seems to be claimed by the kernel.
> 

not convinced. df or findmnt --df all show size (total), used and avail, and
those tools a pretty much standard since decades. total_unpriv is really not
_that_ telling if one comes from the outside, as it isn't clear what unrpiv
refers to at all IMO and why there are two totals, if they should be sumed
together (i.e., is total the one for priv + unrpiv or just priv)...
I'd rather just stick to established defaults/terms and avoid inventing new
ones.