From: Christian Ebner <c.ebner@proxmox.com>
To: Gabriel Goller <g.goller@proxmox.com>
Cc: pbs-devel@lists.proxmox.com
Subject: Re: [pbs-devel] [PATCH proxmox-backup] verify: handle manifest update errors as non-fatal
Date: Wed, 29 Jan 2025 09:15:21 +0100 [thread overview]
Message-ID: <422d7179-74a3-4534-9285-4c3cf01c6afd@proxmox.com> (raw)
In-Reply-To: <v4wenfgq2hjpneyqa7cdinjmzmwa27kbdprdcjs5dfrz5zwj6g@wyatwgzw7mcv>
On 1/28/25 13:43, Gabriel Goller wrote:
> On 28.01.2025 12:47, Christian Ebner wrote:
>> Since commit 8ea00f6e ("allow to abort verify jobs") errors
>> propagated up to the verify jobs worker call side are interpreted as
>> job aborts.
>>
>> The manifest update did not honor this, leading to the verify job
>> being aborted with the misleading log entry:
>> `verification failed - job aborted`
>>
>> Instead, handle the manifest update error non-fatal just like any
>> other verification related error, log it including the error message
>> and continue verification with the next item.
>>
>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>> ---
>> src/backup/verify.rs | 18 +++++++++++++-----
>> 1 file changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/backup/verify.rs b/src/backup/verify.rs
>> index 840a37859..02478b165 100644
>> --- a/src/backup/verify.rs
>> +++ b/src/backup/verify.rs
>> @@ -3,7 +3,7 @@ use std::sync::atomic::{AtomicUsize, Ordering};
>> use std::sync::{Arc, Mutex};
>> use std::time::Instant;
>>
>> -use anyhow::{bail, format_err, Error};
>> +use anyhow::{bail, Error};
>> use nix::dir::Dir;
>> use tracing::{error, info, warn};
>>
>> @@ -399,12 +399,20 @@ pub fn verify_backup_dir_with_lock(
>> state: verify_result,
>> upid,
>> };
>> - let verify_state = serde_json::to_value(verify_state)?;
>> - backup_dir
>> - .update_manifest(|manifest| {
>> +
>> + if let Err(err) = {
>> + let verify_state = serde_json::to_value(verify_state)?;
>> + backup_dir.update_manifest(|manifest| {
>> manifest.unprotected["verify_state"] = verify_state;
>> })
>> - .map_err(|err| format_err!("unable to update manifest blob -
>> {}", err))?;
>> + } {
>> + info!(
>> + "verify {}:{} - manifest update error: {err}",
>> + verify_worker.datastore.name(),
>> + backup_dir.dir(),
>> + );
>
> Is there any reason for not using tracing::error? This would be nice to
> find in the syslog as well. Also using "{err:#}" would print the whole
> error chain/context.
The reason I used `info` over `error` here is that all other errors for
verification are logged the same way, so I would argue that logging only
this one case as error is not correct. If we however decide for using
the `error` over the `info`, I think this should be adapted for all
verification errors being logged, to be consistent.
Regarding error formatting, as the errors by update_manifest do not add
error context, this has no effect currently as far as I see, but you are
right in that this would be more future proof.
Should I send a v2 for that?
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2025-01-29 8:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 11:47 Christian Ebner
2025-01-28 12:43 ` Gabriel Goller
2025-01-29 8:15 ` Christian Ebner [this message]
2025-02-10 10:47 ` [pbs-devel] applied: " Thomas Lamprecht
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=422d7179-74a3-4534-9285-4c3cf01c6afd@proxmox.com \
--to=c.ebner@proxmox.com \
--cc=g.goller@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal