[pbs-devel] [PATCH proxmox 2/2] pbs api types: add option to set GC chunk cleanup wait period

[Thomas Lamprecht]

Am 04.03.25 um 17:37 schrieb Christian Ebner:
> On 3/4/25 17:01, Thomas Lamprecht wrote:
>> Would be fine by me to reducing the minimum to zero. And the extra 5
>> minutes are "just to be sure" safety-margin, not a requirement for
>> anything IIRC.
> 
> Discussed this with Fabian rather extensively today. Only reason to keep 
> a small safety margin here is for small time drift in case of remote 
> storages (if they use their local time for timestamps).

Ah, you mean network attached remote storage, but while your reasons
below are fine, doing this for time drifts is IMO not really strong
argumentation, as if one allows for no time synchronisation then there
won't be a limit to the drift amount, but ...


> But this can be much lower, would opt for 1 minute to stay within the 
> minute range.
> 
> Also, atime always uses the coarse resolution for timestamp updates, 
> that will also not change with the multi-grained timestamp resolutions 
> in https://origin.kernel.org/doc/html/v6.13/filesystems/multigrain-ts.html
> So this has to be taken into account for the atime update check, and 
> since setting the atime into the past will introduce other error modes 
> (permissions, fs impl, ...), a short wait of a 1 second in-between must 
> be used.
> 
> Also, there is no distinction to be made between filesystems mounted 
> with atime and relatime, if the explicit atime update fails, the GC 

... this actually is a strong argument, so I'm fine with a Minute as
minimum.
>> Maybe something with "cutoff", like just gc_cutoff or gc_atime_cutoff,
>> as a cut-off of which chunks we even consider for removal is basically
>> what this is.
> 
> I would opt for gc-atime-safety-check and gc-atime-safety-margin, to 
> show that they are related and their implicit function

meh, do not find safety-check/margin very telling and safety is a bit too
generic and also slightly overused term IMO. What's wrong with cutoff?

> Also, there will be no upper limit for the gc-atime-safety-margin, as 
> Fabian pointed out correctly, setting this to large values might be 
> desired to avoid data loss if something is off, and one notices from 
> e.g. the pending removals.

I'm rather a fan of _some_ limits even if only to be proven wrong by user
demand to go over that, but then we actually know the use case. As until
now we got no request at all for this to be higher, IIRC, I'd go for two
days.

Data loss is prevented by additional copies on other servers and mediums
(keyword: tape or soon s3) not some rather internal GC cut-off that
provides no nice mechanism to recover any data from it, so I also do
not really buy that it will be used as that in practice, we certainly
should not advertise it as candidate for that.