From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id BC38F1FF09F for ; Thu, 03 Sep 2026 15:59:32 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 61C04214FC; Thu, 03 Sep 2026 15:59:32 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 03 Sep 2026 15:59:26 +0200 Message-Id: Subject: Re: [PATCH proxmox-backup v2 3/3] fix #6990: server: drop verify state on non-decrypt pull job From: "Jakob Klocker" To: "Christian Ebner" , X-Mailer: aerc 0.20.0 References: <20260821111826.299588-1-j.klocker@proxmox.com> <20260821111826.299588-4-j.klocker@proxmox.com> <675514ab-3958-471e-82cb-dbcec00f1c4b@proxmox.com> In-Reply-To: <675514ab-3958-471e-82cb-dbcec00f1c4b@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788443964156 X-SPAM-LEVEL: Spam detection results: 0 AWL 1.615 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) KAM_SHORT 0.001 Use of a URL Shortener for very short URL RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 2ISEF53XSSWADAQWSJNDHD3EFEO22RJ4 X-Message-ID-Hash: 2ISEF53XSSWADAQWSJNDHD3EFEO22RJ4 X-MailFrom: j.klocker@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri Aug 28, 2026 at 1:11 PM CEST, Christian Ebner wrote: > Two smaller comments and considerations inline, rest looks good to me! > > On 8/21/26 1:18 PM, Jakob Klocker wrote: >> On a non-decrypt pull the source manifest is written to the target >> as-is, so the target inherits the source's verify_state flag instead of >> being verified independently on its own storage. Because a snapshot >> carrying a verify_state is skipped by verify jobs, the target's copy can >> never be checked. >>=20 >> The decrypt path already drops verify_state; do the same on the >> non-decrypt path when the snapshot is newly pulled or re-synced due to >> corruption. Also factor the manifest blob encoding and writing into a >> helper, shared by both paths. >>=20 >> Link: https://bugzilla.proxmox.com/show_bug.cgi?id=3D6990 >> Signed-off-by: Jakob Klocker >> --- >> pbs-datastore/src/manifest.rs | 25 ++++++++++++++++++- >> src/server/pull.rs | 47 +++++++++++++++++++++++------------ >> 2 files changed, 55 insertions(+), 17 deletions(-) >>=20 >> diff --git a/pbs-datastore/src/manifest.rs b/pbs-datastore/src/manifest.= rs >> index 11de1085b..c87797474 100644 >> --- a/pbs-datastore/src/manifest.rs >> +++ b/pbs-datastore/src/manifest.rs >> @@ -1,5 +1,8 @@ >> -use anyhow::{Error, bail, format_err}; >> +use std::io::Write; >> +use std::os::fd::AsRawFd; >> +use std::path::Path; >> =20 >> +use anyhow::{Context, Error, bail, format_err}; >> use serde::{Deserialize, Serialize}; >> use serde_json::{Value, json}; >> =20 >> @@ -278,6 +281,26 @@ impl BackupManifest { >> =20 >> Ok(Some(Deserialize::deserialize(value)?)) >> } >> + >> + /// Encode the manifest and write the raw blob data to `path`, fsyn= c'ing it. > > comment: I would like for this comment to also include a note/warning=20 > that this should only be used to write manifest files to temp file path= =20 > (or maybe we even want to check/encode that)? If this will be used to=20 > write the mainfest directly, it would lead to concurrent readers to=20 > potentially read incomplete and therefore corrupt manifests. > > Another option and probably even preferable would be for the rename to=20 > be included in this helper as well and maybe pass both, tmp and target=20 > path. From the diff below that should be doable and give us guarantees=20 > that the manifest is persisted atomically. > > > Also this whole content writing could be performed as async via=20 > tokio::fs::File, but taking the performance considerations into account= =20 > [0] it probably is best kept sync for now. Major win would be that this= =20 > could then use `io-uring` for some operations if enabled in tokio in the= =20 > future without code changes, e.g. the OpenOptions used by File have=20 > config and feature flags for this [1]. > > [0] https://docs.rs/tokio/latest/tokio/fs/index.html > [1] https://docs.rs/tokio/latest/src/tokio/fs/open_options.rs.html#122 > I'll add the rename in the helper as well, since I can't think of a case where this helper would be used to write the manifest without renaming it afterwards. This would also make it more clear how this should be used and cover the note/warning concern. Thanks for linking and explaining parts of the tokio=20 documentation, since I haven't used it much yet this information is much appreciated! >> + /// >> + /// Returns the raw blob data. >> + pub fn write_to_path(&self, path: &Path) -> Result, Error> = { > > This could take ownership of the manifest instead, so no further=20 > modifications are to be made afterwards and we can get rid of the Arc=20 > below, since it can be moved without issues into the spawn_blocking call > The reason I reached for Arc is that manifest is used again after the write, in cleanup_unreferenced_files() -- so it can't just be moved into spawn_blocking and dropped. Taking ownership in write_to_path() alone doesn't resolve that; I'd still need a way to get the manifest back or keep a copy. I see three options: - Return the manifest from write_to_path() (e.g. Result<(Vec, Self)>)= =20 and rebind it for the cleanup call. - Derive Clone on BackupManifest and clone before moving into spawn_blocking. - Keep the Arc I went with Arc as it felt like the least invasive option, but I'm happy to switch. Do you have a preference, or am I missing something here? >> + let raw_data =3D self.to_data_blob(None)?.raw_data().to_vec(); >> + >> + let mut file =3D std::fs::OpenOptions::new() >> + .write(true) >> + .create(true) >> + .truncate(true) >> + .open(path) >> + .with_context(|| format!("failed to open manifest {path:?}"= ))?; >> + >> + file.write_all(&raw_data)?; >> + file.flush()?; >> + nix::unistd::fsync(file.as_raw_fd())?; >> + >> + Ok(raw_data) >> + } >> } >> =20 >> >> [SNIP]