Re: [pbs-devel] [PATCH proxmox-backup 4/4] docs: add description for gc-cache-capacity tuning parameter

From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>,
	Lukas Wagner <l.wagner@proxmox.com>,
	Christian Ebner <c.ebner@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup 4/4] docs: add description for gc-cache-capacity tuning parameter
Date: Fri, 4 Apr 2025 14:20:07 +0200	[thread overview]
Message-ID: <546d1c9a-f87c-40d1-af45-54b8a0b7abd9@proxmox.com> (raw)
In-Reply-To: <17935971-dc70-4288-85d2-a7d125a61756@proxmox.com>

Am 04.04.25 um 13:58 schrieb Lukas Wagner:
> I think we could completely omit the "the capacity is set as the given value multiplied by 1024" sentence here
> and consider the fact that the LRU cache size is value * 1024 an implementation detail.

But once that option is available it's part of the API and not just
an implementation detail anymore?

> For the user, the exact number of cached digests in the backend is probably not really that important, right?
> In reality, they just want some knob that they can adjust in a range from 0 (no caching) to some maximum.

For some, probably even a lot, users it might be indeed enough to
like double or half the number depending on if they want to improve
performance or reduce memory footprint.

But I know users that have a hard time working with a numerical
setting without knowing what it's exactly doing on a lower level, at
least for me such settings are often rather irritating, as I cannot
really have a good thought process for how I'd choose the number
depending on what I want to achieve.

So while I agree with your underlying point, I'd still like users
being able to relatively easily find out how much change translates
in what impact.

> Same of course applies also for the GUI patch and the log message.
> 
> What do you think?

Two alternatives:
- Changes this to the shift width, i.e. the x from 2^x, similar to the
  ZFS setting. Makes it nice small number to configure and for most
  use cases the exponential nature should be still granular enough.
  That said, it's not very user-friendly, at least to those without
  some level of CS background or the like.

- just drop the * 1024 factor and allow users to enter the full number,
  it then can be simply described as numbers of chunks which is trivial
  to understand and relate too.

Personally I'd favor the second option, mainly because it's so simple,
and having big numbers here is not that of a huge problem.

ps. secret option three: adapt the human byte selector in the frontend
to expose selecting kilo-chunks and mega-chunks ;-)

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