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

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On March 4, 2025 5:49 pm, Thomas Lamprecht wrote:
> Am 04.03.25 um 17:37 schrieb Christian Ebner:
>> 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.

that's true, keeping the chunks for a longer period just makes
recovering from an accidental "over-pruning" much faster (by syncing
just the metadata back from whichever offsite copy), it doesn't
allow recovering on its own without an extra copy.

so if your datastore has the headroom, bumping the limit to a week for
example and monitoring your GC stats to notice pending removal outliers
can save you days of copying chunks back..

it's probably not a very common use case though, and temporarily or
permanently reducing it down to a very low bound will probably be the
common (and maybe future default) setting ;)


_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel