public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Christian Ebner <c.ebner@proxmox.com>
To: "Thomas Lamprecht" <t.lamprecht@proxmox.com>,
	"Proxmox Backup Server development discussion"
	<pbs-devel@lists.proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pbs-devel] [PATCH v2 proxmox-backup] garbage collection: fix rare race in chunk marking phase
Date: Wed, 16 Apr 2025 08:31:01 +0200	[thread overview]
Message-ID: <15aa6233-1e5a-439e-b4fd-1f57afceb699@proxmox.com> (raw)
In-Reply-To: <7bac779b-e564-4f24-b58c-a4411c2a59aa@proxmox.com>

Hi Thomas,

On 4/15/25 17:40, Thomas Lamprecht wrote:
> On 15/04/2025 15:14, Fabian Grünbichler wrote:
>>>> this should check the result? this would also fail if a backup is
>>>> currently going on (very likely if we end up here?) and abort the GC
>>>> then, but we don't have a way to lock a group with a timeout at the
>>>> moment.. but maybe we can wait and see if users actually run into that,
>>>> we can always extend the locking interface then..
>>> True, but since this is very unlikely to happen, I would opt to fail and
>>> add an error context here so this can easily be traced back to this code
>>> path.
>> yes, for now I'd say aborting GC with a clear error here is best. we
>> cannot safely continue..
> 
> Did not check v3, but note that users often do not run GC with a high
> frequency due to the load it generates and time it needs, but still
> depend on it to finish so space is being freed.
> 
> So if there is any way we can go or add to avoid aborting completely,
> it would be IMO quite worth to evaluate doing that more closely.
> 
> FWIW, an completely different alternative might be to not change
> GC but pruning when a GC job runs, e.g. (spitballing/hand waving)
> move the index to a trash folder and notify GC about that.

yes, having some sort of shadow copy of the index files came to mind as 
well. I did however disregard that for the GC itself, because it would 
be expensive and probably run into similar races with pruning.

Your suggested approach would however eliminate that, and further also 
be a nice feature! GC could then clean up all the trashed index files 
with some retention logic in a new phase 3, after cleaning up the chunks.

E.g. it already happened to some users that they pruned a snapshot they 
still needed by accident. So might it make sense to add a trash can as 
feature?

Nevertheless, I do think that changing the order of snapshot iteration 
for the GC run should be reversed, as that even further reduces the 
window of opportunity where things can go wrong (as stated in my 
self-reply to version 3 of the patch).


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

  reply	other threads:[~2025-04-16  6:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-15 10:54 Christian Ebner
2025-04-15 11:42 ` Fabian Grünbichler
2025-04-15 12:50   ` Christian Ebner
2025-04-15 13:14     ` Fabian Grünbichler
2025-04-15 15:40       ` Thomas Lamprecht
2025-04-16  6:31         ` Christian Ebner [this message]
2025-04-16  7:11           ` Fabian Grünbichler
2025-04-15 14:51 ` [pbs-devel] superseded: " Christian Ebner

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=15aa6233-1e5a-439e-b4fd-1f57afceb699@proxmox.com \
    --to=c.ebner@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=t.lamprecht@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal