all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Proxmox Backup Server development discussion"
	<pbs-devel@lists.proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: [pbs-devel] applied: [PATCH proxmox-backup] chunk store: handle insertion edge cases
Date: Thu, 6 Apr 2023 09:38:23 +0200	[thread overview]
Message-ID: <ee5a4a72-d0cc-c596-2e19-22e34856769b@proxmox.com> (raw)
In-Reply-To: <20230331084345.3971666-1-f.gruenbichler@proxmox.com>

Am 31/03/2023 um 10:43 schrieb Fabian Grünbichler:
> these were previously called out in a comment, but should now be handled (as
> much as they can be).
> 
> the performance impact shouldn't be too bad, since we only look at the magic 8
> bytes at the start of the existing chunk (we already did a stat on it, so that
> might even be prefetched already by storage), and only if there is a size
> mismatch and encryption is enabled.
> 
> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
> ---
> 
> Notes:
>     we could verify the CRC when deciding between existing and incoming encrypted
>     chunk, but that would require reading the full chunk, and that would be quite
>     the load if we ever upgrade ZSTD or change its parameters and the new version
>     is substantially better or worse at compressing.. the CRC is verified on
>     every regular load (such as verify, sync, restore) anyway.
>     
>     we cannot decide which of the two potentially invalid encrypted chunks to keep
>     based on the size and compression status: uncompressed chunks should always
>     be bigger than compressed ones, but both the size and the compression bit is
>     100% under a potential attacker's control anyhow, so we cannot prevent them
>     from sending us rather small chunks that we still need to discard out of
>     caution, even if they are smaller than the existing one.
> 
>  pbs-datastore/src/chunk_store.rs | 36 ++++++++++++++++++++++++++------
>  pbs-datastore/src/data_blob.rs   |  6 ++++++
>  2 files changed, 36 insertions(+), 6 deletions(-)
> 
>

applied, with touch_chunk calls amended like discussed off-list, thanks!




      reply	other threads:[~2023-04-06  7:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31  8:43 [pbs-devel] " Fabian Grünbichler
2023-04-06  7:38 ` Thomas Lamprecht [this message]

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=ee5a4a72-d0cc-c596-2e19-22e34856769b@proxmox.com \
    --to=t.lamprecht@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