From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Shannon Sterz" <s.sterz@proxmox.com>,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
"Proxmox Backup Server development discussion"
<pbs-devel@lists.proxmox.com>,
"Wolfgang Bumiller" <w.bumiller@proxmox.com>
Subject: Re: [pbs-devel] [PATCH backup] fix #3336: cleanup when deleting last snapshot
Date: Tue, 11 Mar 2025 11:40:45 +0100 [thread overview]
Message-ID: <3f881f04-cec3-4cef-a5b4-7c5b9177058e@proxmox.com> (raw)
In-Reply-To: <D8DCFI6B5TRU.36EQEELU5U3MO@proxmox.com>
On 11/03/2025 10:52, Shannon Sterz wrote:
>> That's what the flag is for, touch it on upgrade before the new daemon
>> starts, in the new daemon set an internal global OnceLock (or the like)
>> guarded flag and use that to determine if old or new locking needs to be
>> used. On the next reboot the flag won't be there anymore and thus new
>> locking mode is used.
> hm since this was sparked by the group removal bug (the one that leaves
> the owner file in place), that would mean we can only fix that once we
> are sure that the new locking mechanism is used? or do we build in that
> contingency there too?
At least the global flag could be checked there too and one could select
behavior based on that, if sensible.
While the overhead on our (dev) side is slightly higher, it's not that
high with rust. And FWIW dropping it again should be relatively easy,
one can just remove the flag and then clean up all compile errors that
are caused by that removal, rinse and repeat style.
I do not want to set that solution in stone, but IMO our maintenance
cost amplification will be relatively low while the one for users won't
be, just by the fact that we got a few orders of magnitudes more users
than devs, so if above is really feasible (it has been a while since
we thought this through and tbh. I did not recheck if that was the
exact same solution we came up last time) then it should be worth the
small hassle we have do deal with for one major release.
> can send a v7 that adds the locking strategy switch later today
> probably.
Could be worth to wait on Fabian having a solid objection here, or
discuss that directly – given you both are desk neighbours ^^ – to
avoid potential extra work.
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
prev parent reply other threads:[~2025-03-11 10:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 12:08 Maximiliano Sandoval
2025-03-07 10:37 ` Shannon Sterz
2025-03-07 15:33 ` Wolfgang Bumiller
2025-03-07 15:53 ` Shannon Sterz
2025-03-10 10:53 ` Wolfgang Bumiller
2025-03-10 15:19 ` Fabian Grünbichler
2025-03-10 15:22 ` Shannon Sterz
2025-03-11 9:21 ` Thomas Lamprecht
2025-03-11 9:52 ` Shannon Sterz
2025-03-11 10:40 ` Thomas Lamprecht [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=3f881f04-cec3-4cef-a5b4-7c5b9177058e@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=f.gruenbichler@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=s.sterz@proxmox.com \
--cc=w.bumiller@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.