From: Christoph Heiss <c.heiss@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [RFC PATCH v2 proxmox-backup{, -qemu}, pve-{qemu, manager}, qemu-server 0/7] fix #4289: Set protected flag on backup creation
Date: Thu, 26 Jan 2023 13:44:35 +0100 [thread overview]
Message-ID: <20230126124435.xrk5bwm2jt242tk2@maui.proxmox.com> (raw)
In-Reply-To: <e81b304c-3d71-c906-5dce-0d7e728d59d1@proxmox.com>
On Wed, Jan 25, 2023 at 05:00:03PM +0100, Thomas Lamprecht wrote:
> Am 25/01/2023 um 13:18 schrieb Christoph Heiss:
> > When a datastore has the "Verify New Snapshots" flag set and a backup
> > with the protected flag set is created (e.g. using `vzdump --protected 1
> > ..`), the job might fail in the final stages due to a locking race. The
> > "Verify New Snapshots" flag means that backups are immediately locked for
> > verification as soon as their transfer is finished and the `/finish`
> > endpoint is called.
> >
> > If vzdump then tries to set the `protected` flag on that backup, it can
> > fail due to being currently locked by the verification task.
>
> but the protection flag resides in the "unprotected" part of the manifest,
> and IMO it seems very odd that I cannot change a protection flag if verification
> is running, which can happen anytime not only on verify-new.
Hm, I did indeed not consider this case - this really seems a bit quirky
then after all.
>
> So why not adapt this that protection can be changed independent of verification,
> which would require zero client changes and make for a better UX in general -
> albeit it certainly needs some well thought out (lock) handling.
I will look into this, thanks for the hint! I tried messing with the
locking before, which wasn't all that fruitfully.
In any case, definitely seems like the right way for this now, plus it
would make things a lot cleaner. Did not know that the protection flag
was generally a "unprotected" part of the manifest, this of course
changes things.
prev parent reply other threads:[~2023-01-26 12:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 12:18 Christoph Heiss
2023-01-25 12:18 ` [pbs-devel] [RFC PATCH v2 proxmox-backup 1/7] api2: Introduce server features discovery mechanism Christoph Heiss
2023-01-25 15:56 ` Thomas Lamprecht
2023-01-26 12:33 ` Christoph Heiss
2023-01-25 12:18 ` [pbs-devel] [RFC PATCH v2 proxmox-backup 2/7] api2: Add `protected` parameter to `finish` endpoint Christoph Heiss
2023-01-25 12:18 ` [pbs-devel] [RFC PATCH v2 proxmox-backup 3/3] client: Add `--protected` CLI flag to backup command Christoph Heiss
2023-01-25 12:18 ` [pbs-devel] [RFC PATCH v2 proxmox-backup-qemu 4/7] api: Supply `protected` parameter to the `finish` API call Christoph Heiss
2023-01-25 12:19 ` [pbs-devel] [RFC PATCH v2 pve-qemu 5/7] pve: Add patch to support new proxmox-backup-qemu API Christoph Heiss
2023-01-25 12:19 ` [pbs-devel] [RFC PATCH v2 qemu-server 6/7] vzdump: Set protected flag on backup start if supported Christoph Heiss
2023-01-25 12:19 ` [pbs-devel] [RFC PATCH v2 pve-manager 7/7] vzdump: Only set protected attribute if not already done Christoph Heiss
2023-01-25 16:00 ` [pbs-devel] [RFC PATCH v2 proxmox-backup{, -qemu}, pve-{qemu, manager}, qemu-server 0/7] fix #4289: Set protected flag on backup creation Thomas Lamprecht
2023-01-26 12:44 ` Christoph Heiss [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=20230126124435.xrk5bwm2jt242tk2@maui.proxmox.com \
--to=c.heiss@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=t.lamprecht@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