From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Christoph Heiss <c.heiss@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: Wed, 25 Jan 2023 17:00:03 +0100 [thread overview]
Message-ID: <e81b304c-3d71-c906-5dce-0d7e728d59d1@proxmox.com> (raw)
In-Reply-To: <20230125121902.404950-1-c.heiss@proxmox.com>
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.
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.
next prev parent reply other threads:[~2023-01-25 16:00 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 ` Thomas Lamprecht [this message]
2023-01-26 12:44 ` [pbs-devel] [RFC PATCH v2 proxmox-backup{, -qemu}, pve-{qemu, manager}, qemu-server 0/7] fix #4289: Set protected flag on backup creation Christoph Heiss
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=e81b304c-3d71-c906-5dce-0d7e728d59d1@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=c.heiss@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