[pbs-devel] [PATCH v2 proxmox{, -backup} 0/2] Move ProcessLocker to tmpfs
Thomas Lamprecht
t.lamprecht at proxmox.com
Wed Dec 6 15:58:01 CET 2023
Am 06/12/2023 um 15:46 schrieb Gabriel Goller:
> On 12/6/23 15:36, Thomas Lamprecht wrote:
>> Am 06/12/2023 um 14:41 schrieb Fabian Grünbichler:
>>> [..]
>> Wolfgang and I discussed this last week or so, and we'd use a flag living
>> in `/run/proxmox-backup` touched via proxmox-backup-server.postinst on
>> upgrade to signal that the new locking should not be used yet, after reboot
>> all old daemons are gone and so is the flag, so the new locking can be used.
>>
>> Manual downgrades we don't care for, as those need special attention anyway.
>> The duplicate code can then be ripped out in the next major release.
>>
>> Wolfgang has a PoC about this on his staff repo IIRC.
> We should also add a section in the upgrade guide on how to upgrade
> *without*
> rebooting, so stopping all old processes, removing the flag manually,
> updating,
> then starting the new process. (I'd guess a lot of people don't want to
> reboot)
I'd not bother too much with that, besides discoverability, these are
actions that can lead to data loss if done slightly wrong (reload
instead of restart)..
If any new big feature is better off with the new locking, like the
removable datastore is, then that feature should actively check and
warn/hint if the old mechanism is still active and the release note
can contain a hint about requiring a reboot.
Long uptimes are most of the time a bad sign anyway (kernel live
patching isn't a 100% replacement to full updates via reboot).
More information about the pbs-devel
mailing list