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 97BD31FF15F
	for <inbox@lore.proxmox.com>; Mon, 18 Nov 2024 16:04:27 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id 96E4412EAF;
	Mon, 18 Nov 2024 16:04:32 +0100 (CET)
Mime-Version: 1.0
Date: Mon, 18 Nov 2024 16:04:28 +0100
Message-Id: <D5PEAMB5N1OO.3V8CYGRY6VD3R@proxmox.com>
From: "Shannon Sterz" <s.sterz@proxmox.com>
To: "Proxmox Backup Server development discussion"
 <pbs-devel@lists.proxmox.com>
X-Mailer: aerc 0.17.0-69-g65571b67d7d3-dirty
References: <20241118092435.81880-1-c.ebner@proxmox.com>
 <20241118092435.81880-4-c.ebner@proxmox.com>
In-Reply-To: <20241118092435.81880-4-c.ebner@proxmox.com>
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.043 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 docs 3/3] docs: client: fix formatting by
 using double ticks
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 Mon Nov 18, 2024 at 10:24 AM CET, Christian Ebner wrote:
> With single ticks the containing modes and archive formats are
> displayed cursive, to be consistent with other sections of the
> documentation use inline blocks.
>
> Adapted line wrappings to the additional line length.
>
> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
> ---
>  docs/backup-client.rst | 25 +++++++++++++------------
>  1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/docs/backup-client.rst b/docs/backup-client.rst
> index 78e856979..45df440c9 100644
> --- a/docs/backup-client.rst
> +++ b/docs/backup-client.rst
> @@ -295,19 +295,20 @@ therefore deduplicated). If the backed up files are largely unchanged,
>  re-reading and then detecting the corresponding chunks don't need to be uploaded
>  after all is time consuming and undesired.
>
> -The backup client's `change-detection-mode` can be switched from default to
> -`metadata` based detection to reduce limitations as described above, instructing
> -the client to avoid re-reading files with unchanged metadata whenever possible.
> +The backup client's ``change-detection-mode`` can be switched from default to
> +``metadata`` based detection to reduce limitations as described above,
> +instructing the client to avoid re-reading files with unchanged metadata
> +whenever possible.
>  When using this mode, instead of the regular pxar archive, the backup snapshot
> -is stored into two separate files: the `mpxar` containing the archive's metadata
> -and the `ppxar` containing a concatenation of the file contents. This splitting
> -allows for efficient metadata lookups. When creating the backup archives, the
> -current file metadata is compared to the one looked up in the previous `mpxar`
> -archive. The operational details are explained more in depth in the
> -:ref:`technical documentation <change-detection-mode-metadata>`.
> -
> -Using the `change-detection-mode` set to `data` allows to create the same split
> -archive as when using the `metadata` mode, but without using a previous
> +is stored into two separate files: the ``mpxar`` containing the archive's
> +metadata and the ``ppxar`` containing a concatenation of the file contents. This
> +splitting allows for efficient metadata lookups. When creating the backup
> +archives, the current file metadata is compared to the one looked up in the
> +previous ``mpxar`` archive. The operational details are explained more in depth
> +in the :ref:`technical documentation <change-detection-mode-metadata>`.
> +
> +Using the ``change-detection-mode`` set to ``data`` allows to create the same
> +split archive as when using the ``metadata`` mode, but without using a previous
>  reference and therefore reencoding all file payloads. For details of this mode
>  please see the :ref:`technical documentation <change-detection-mode-data>`.
>

read through all these doc patches, they sound good to me


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