From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 8697092987 for ; Mon, 8 Apr 2024 11:21:04 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 615DE70D4 for ; Mon, 8 Apr 2024 11:20:34 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 8 Apr 2024 11:20:33 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 2A8D54457F for ; Mon, 8 Apr 2024 11:20:33 +0200 (CEST) Date: Mon, 08 Apr 2024 11:20:28 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox Backup Server development discussion References: <20240405130543.259220-1-h.duerr@proxmox.com> <20240405130543.259220-2-h.duerr@proxmox.com> In-Reply-To: <20240405130543.259220-2-h.duerr@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1712567154.6c6yxorn2q.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.058 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [wikipedia.org, proxmox.com] Subject: Re: [pbs-devel] [PATCH proxmox-backup v2 1/3] docs: centralise and update garbage collection description X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2024 09:21:04 -0000 On April 5, 2024 3:05 pm, Hannes Duerr wrote: > The "backup client usage" chapter describes a grace period that is 24 > hours and 5 minutes long, and unconnected to this a cut-off time is > mentioned under "maintenance tasks", which leads to confusion. Therefore > we summarise the entire description of garbage collection under > "maintenance tasks" and link to it in the "backup client usage" chapter >=20 > Signed-off-by: Hannes Duerr > --- > docs/backup-client.rst | 16 +++--------- > docs/maintenance.rst | 57 ++++++++++++++++++++++++++++++------------ > 2 files changed, 44 insertions(+), 29 deletions(-) >=20 > diff --git a/docs/backup-client.rst b/docs/backup-client.rst > index 00a1abbb..d015b844 100644 > --- a/docs/backup-client.rst > +++ b/docs/backup-client.rst > @@ -735,25 +735,15 @@ command. It is recommended to carry out garbage col= lection on a regular basis. > =20 > The garbage collection works in two phases. In the first phase, all > data blocks that are still in use are marked. In the second phase, > -unused data blocks are removed. > +unused data blocks are removed. A more detailed description of the GC > +can be found :ref:`here `. > + > =20 > .. note:: This command needs to read all existing backup index files > and touches the complete chunk-store. This can take a long time > depending on the number of chunks and the speed of the underlying > disks. > =20 > -.. note:: The garbage collection will only remove chunks that haven't be= en used > - for at least one day (exactly 24h 5m). This grace period is necessary= because > - chunks in use are marked by touching the chunk which updates the ``at= ime`` > - (access time) property. Filesystems are mounted with the ``relatime``= option > - by default. This results in a better performance by only updating the > - ``atime`` property if the last access has been at least 24 hours ago.= The > - downside is that touching a chunk within these 24 hours will not alwa= ys > - update its ``atime`` property. > - > - Chunks in the grace period will be logged at the end of the garbage > - collection task as *Pending removals*. > - > .. code-block:: console > =20 > # proxmox-backup-client garbage-collect > diff --git a/docs/maintenance.rst b/docs/maintenance.rst > index 6dbb6941..e25c8f19 100644 > --- a/docs/maintenance.rst > +++ b/docs/maintenance.rst > @@ -171,8 +171,8 @@ It's recommended to setup a schedule to ensure that u= nused space is cleaned up > periodically. For most setups a weekly schedule provides a good interval= to > start. > =20 > -GC Background > -^^^^^^^^^^^^^ > +Overview > +^^^^^^^^ > =20 > In `Proxmox Backup`_ Server, backup data is not saved directly, but rath= er as > chunks that are referred to by the indexes of each backup snapshot. This > @@ -187,26 +187,51 @@ references to the same chunks on every snapshot del= etion. Moreover, locking the > entire datastore is not feasible because new backups would be blocked un= til the deletion > process was complete. > =20 > -Therefore, Proxmox Backup Server uses a garbage collection (GC) process = to > +Therefore, Proxmox Backup Server uses a `tracing garbage collection > +`_ algorithm t= o > identify and remove the unused backup chunks that are no longer needed b= y any > -snapshot in the datastore. The GC process is designed to efficiently rec= laim > +snapshot in the datastore. The GC algorithm is designed to efficiently r= eclaim > the space occupied by these chunks with low impact on the performance of= the > datastore or interfering with other backups. > =20 > -The garbage collection (GC) process is performed per datastore and is sp= lit > -into two phases: > +The GC is performed per datastore and is split into two phases: > =20 > -- Phase one: Mark > - All index files are read, and the access time of the referred chunk fi= les is > - updated. > +- Phase one - Mark: > + > + Read all index files and update the ``atime`` (access time) of the rel= evant > + chunk files. I'd replace "relevant" with "referenced" here, it is more concrete and matches the terminology below > + > +- Phase two - Sweep: > + > + Iterate over all chunks and check the ``atime`` of the files. If > + the ``atime`` is older than the cut-off time, the chunk was neither > + referenced in a backup index nor is it part of a running backup that > + does not yet have an index to search. As such, safely remove the chunk= . nor was it recently created as part of a running backup task, but is not referenced yet by any finished index file. Such chunks can be safely removed since they are no longer needed. (Safely remove implies that we do some special removing that is safe ;)) > + > + > +Cut-off Time > +^^^^^^^^^^^^ > + > +The GC only clears the chunks that were last accessed before the s/clears/removes/ > +cut-off time. The cut-off time is determined by whichever is earlier: is determined *at the start of the GC task* this is an important detail that helps understanding for more technically inclined readers > + > +- 24 hours and 5 minutes before the start of the garbage collection > + due to the mounting of the data storage with ``relatime``, or "before the start of .. due to" is a bit confusing. maybe: - 24 hours before the start of the garbage collection (to account for the datastore potentially being mounted with ``relatime``). > + > +- the start time of the oldest active backup job that has been running > + for longer than 24 hours and 5 minutes at the beginning of the > + garbage collection. This is necessary because the newly created > + backup could refer to blocks, but the GC would not notice this as > + there is no index of the backup that could be searched. the whole "that has been" can be dropped. the cut off is determined by whichever is earlier: - now - 24h - start time of oldest backup writer with an extra 5m of safety margin added in any case - not just the 24h one! - the start time of the oldest active backup job (to account for newly written chunks that are not yet referenced by any finished snapshot) is a bit shorter and IMHO conveys the same information > + > +Chunks accessed after the cut-off time are marked as *Pending removals* > +by the GC as it cannot be certain whether they are still needed. this is rather incomplete and a bit hard to parse as well. I'd replace "accessed after" with "with an atime after". pending is actually: - chunks with atime between the cut-off and the oldest writer (if one exists) - chunks with atime between the cut-off and the start of GC (if no writer exists at the start) this normally means chunks of snapshots which have been recently forgotten/pruned. it can also mean freshly uploaded chunks of recently aborted backup tasks. > + > +.. Note:: Mounting a volume with ``relatime`` means that the ``atime`` > + of the chunk files is not updated every time, but only when the > + data has changed or the ``atime`` was before a certain time, > + which is 24 hours by default. > =20 > -- Phase two: Sweep > - The task iterates over all chunks, checks their file access time, and = if it > - is older than the cutoff time (i.e., the time when GC started, plus so= me > - headroom for safety and Linux file system behavior), the task knows th= at the > - chunk was neither referred to in any backup index nor part of any curr= ently > - running backup that has no index to scan for. As such, the chunk can b= e > - safely deleted. > =20 > Manually Starting GC > ^^^^^^^^^^^^^^^^^^^^ > --=20 > 2.39.2 >=20 >=20 >=20 > _______________________________________________ > pbs-devel mailing list > pbs-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel >=20 >=20 >=20