all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "Jakob Klocker" <j.klocker@proxmox.com>
To: "Christian Ebner" <c.ebner@proxmox.com>, <pbs-devel@lists.proxmox.com>
Subject: Re: [PATCH proxmox-backup 1/2] fix #6990: server: drop verify state on non-decrypt pull job
Date: Fri, 24 Jul 2026 10:11:31 +0200	[thread overview]
Message-ID: <DK6NEDR3PHU4.1II662BRRJS88@proxmox.com> (raw)
In-Reply-To: <901201f6-9e5d-4470-8059-3016473b0944@proxmox.com>

Thanks for the feedback!

On Thu Jul 23, 2026 at 1:08 PM CEST, Christian Ebner wrote:
> Thanks for the patch, mostly looks good to me.
>
> Just one comment and nit inline.
>
> On 7/9/26 2:22 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.
>> 
>> 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.
>> 
>> Link: https://bugzilla.proxmox.com/show_bug.cgi?id=6990
>>   
>>[SNIP]
>> +async fn write_manifest_blob(
>> +    manifest: &BackupManifest,
>> +    path: &std::path::Path,
>> +) -> Result<Vec<u8>, Error> {
>> +    let manifest_blob = DataBlob::encode(manifest.to_string(None)?.as_bytes(), None, true)?;
>> +    let manifest_data = manifest_blob.raw_data().to_vec();
>> +    let mut manifest_file = OpenOptions::new()
>> +        .write(true)
>> +        .truncate(true)
>> +        .open(path)
>> +        .await?;
>> +    manifest_file.write_all(&manifest_data).await?;
>> +    manifest_file.flush().await?;
>> +    nix::unistd::fsync(manifest_file.as_raw_fd())?;
>
> nit: pre-existing but this is a blocking call and we are in an async 
> context, so we should spawn a blocking tokio task for this I guess. Same 
> is true for the std::fs::rename which should be replaced by it's 
> tokio::fs::rename counterpart and the call to 
> BackupDir::cleanup_unreferenced_files().
>
> Could you also include additional patches to fix these since touching this?
>

I'll make sure to fix these in a v2.

>> +    Ok(manifest_data)
>> +}
>
> comment: This should rather live as method impl on BackupManifest itself 
> IMO. It could further be refactored to reduce common code with 
> pbs-datastores BackupDir::update_manifest().
>

Makes sense moving this to BackupManifest. Thanks for pointing me to
`update_manifest`, I'll further refactor this.

>>   /// Check if the decryption key should be used to decrypt the snapshot during
>>   /// pull based on given pull parameter, source and optionally already present
>>   /// target manifest.





  reply	other threads:[~2026-07-24  8:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 12:21 [PATCH proxmox-backup 0/2] fix #6990: server: drop verify state on push & pull job Jakob Klocker
2026-07-09 12:21 ` [PATCH proxmox-backup 1/2] fix #6990: server: drop verify state on non-decrypt " Jakob Klocker
2026-07-23 11:08   ` Christian Ebner
2026-07-24  8:11     ` Jakob Klocker [this message]
2026-07-09 12:21 ` [PATCH proxmox-backup 2/2] fix #6990: server: drop verify state on push job Jakob Klocker

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=DK6NEDR3PHU4.1II662BRRJS88@proxmox.com \
    --to=j.klocker@proxmox.com \
    --cc=c.ebner@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