From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pbs-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
	by lore.proxmox.com (Postfix) with ESMTPS id E89141FF189
	for <inbox@lore.proxmox.com>; Fri,  4 Apr 2025 13:58:24 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id 2CBA31D8B0;
	Fri,  4 Apr 2025 13:58:13 +0200 (CEST)
Message-ID: <17935971-dc70-4288-85d2-a7d125a61756@proxmox.com>
Date: Fri, 4 Apr 2025 13:58:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Proxmox Backup Server development discussion
 <pbs-devel@lists.proxmox.com>, Christian Ebner <c.ebner@proxmox.com>
References: <20250403122732.369087-1-c.ebner@proxmox.com>
 <20250403122732.369087-4-c.ebner@proxmox.com>
Content-Language: de-AT, en-US
From: Lukas Wagner <l.wagner@proxmox.com>
In-Reply-To: <20250403122732.369087-4-c.ebner@proxmox.com>
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.014 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DMARC_MISSING             0.1 Missing DMARC policy
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pbs-devel] [PATCH proxmox-backup 4/4] docs: add description
 for gc-cache-capacity tuning parameter
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
 <pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox Backup Server development discussion
 <pbs-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pbs-devel-bounces@lists.proxmox.com
Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com>



On  2025-04-03 14:27, Christian Ebner wrote:
> Adds a bullet point to the listed datastore tuning parameters,
> describing its functionality, implications and typical values.
> 
> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
> ---
>  docs/storage.rst | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/storage.rst b/docs/storage.rst
> index 490302955..cab65ef79 100644
> --- a/docs/storage.rst
> +++ b/docs/storage.rst
> @@ -435,9 +435,17 @@ There are some tuning related options for the datastore that are more advanced:
>  
>    This can be set with:
>  
> -.. code-block:: console
> +  .. code-block:: console
> +
> +    # proxmox-backup-manager datastore update <storename> --tuning 'sync-level=filesystem'
>  
> -  # proxmox-backup-manager datastore update <storename> --tuning 'sync-level=filesystem'
> +* ``gc-cache-capacity``: Datastore GC least recently used cache capacity:
> +  Allows to control the cache capacity used to keep track of chunks for which
> +  the access time has already been updated during phase 1 of garbage collection.
> +  This avoids multiple updates and increases GC runtime performance. The
> +  capacity is set as the given value multiplied by 1024. Higher values can
> +  reduce GC runtime at the cost of increase memory usage, setting the value to 0
> +  disables caching.

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.
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.

Same of course applies also for the GUI patch and the log message.

What do you think?

-- 
- Lukas



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