all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Christian Ebner <c.ebner@proxmox.com>
To: "Proxmox Backup Server development discussion"
	<pbs-devel@lists.proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup 0/3] reduce GC S3 locking
Date: Fri, 21 Nov 2025 11:05:51 +0100	[thread overview]
Message-ID: <88f715f6-c5bb-4787-ba63-12fe965066d3@proxmox.com> (raw)
In-Reply-To: <20251121090605.262675-1-f.gruenbichler@proxmox.com>

On 11/21/25 10:06 AM, Fabian Grünbichler wrote:
> this patch series tries to reduce the number of open locks held by GC,
> in particular in case most objects returned by the S3 backend are
> garbage that need deletion.
> 
> the first patch reduces the number of open locks by at least a factor of
> 10 in the worst case (from up to 1000 to up to 100).
> 
> the second patch just refactors some now common code.
> 
> the third patch tries to reduce the number of delete calls for regular
> GC runs by batching deletes more efficiently.
> 
> Fabian Grünbichler (3):
>    GC: S3: reduce number of open FDs for to-be-deleted objects
>    GC: S3: factor out batch object deletion
>    GC: S3: phase2: delete last partial batch of objects at the very end
> 
>   pbs-datastore/src/datastore.rs | 49 +++++++++++++++++++++++-----------
>   1 file changed, 33 insertions(+), 16 deletions(-)
> 

Apart from the off by one error the patches look good to me and 
significantly reduce the likelihood to run into the soft limit for open 
files. And as a positive side effect, this makes garbage collection even 
more efficient when only a limited number of chunks per list batch has 
to be removed, collecting them into a reduced number of API calls.

With the one issue addressed, consider:

Reviewed-by: Christian Ebner <c.ebner@proxmox.com>
Tested-by: Christian Ebner <c.ebner@proxmox.com>


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

  parent reply	other threads:[~2025-11-21 10:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21  9:05 Fabian Grünbichler
2025-11-21  9:05 ` [pbs-devel] [PATCH proxmox-backup 1/3] GC: S3: reduce number of open FDs for to-be-deleted objects Fabian Grünbichler
2025-11-21  9:43   ` Christian Ebner
2025-11-21  9:06 ` [pbs-devel] [PATCH proxmox-backup 2/3] GC: S3: factor out batch object deletion Fabian Grünbichler
2025-11-21  9:06 ` [pbs-devel] [PATCH proxmox-backup 3/3] GC: S3: phase2: delete last partial batch of objects at the very end Fabian Grünbichler
2025-11-21  9:31   ` Christian Ebner
2025-11-21  9:46     ` Fabian Grünbichler
2025-11-21  9:53       ` Christian Ebner
2025-11-21 10:05 ` Christian Ebner [this message]
2025-11-21 10:19 ` [pbs-devel] superseded: [PATCH proxmox-backup 0/3] reduce GC S3 locking Fabian Grünbichler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=88f715f6-c5bb-4787-ba63-12fe965066d3@proxmox.com \
    --to=c.ebner@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal