[pbs-devel] [PATCH v2 proxmox{, -backup} 0/2] Move ProcessLocker to tmpfs

[Thomas Lamprecht]

Am 06/12/2023 um 14:41 schrieb Fabian Grünbichler:
> 
>> Gabriel Goller <g.goller at proxmox.com> hat am 06.12.2023 14:28 CET geschrieben:
>> This moves the `ProcessLocker`'s `.lock` file to `/run/proxmox-backup/locks` (tmpfs).
>>
>> The first patch only converts all the `F_SETLK` flags to `F_OFD_SETLK` flags. This
>> changes normal locks, which are based on the process, to locks based on an open file
>> descriptor. This actually doesn't change anything, because we use mutexes, so the
>> lock is already thread-safe. It would be cleaner though and would safe us from
>> weird quirks like closing the lock-file which would drop all the locks when using
>> the POSIX `F_SETLK`. See more here [0].
> 
> this might be moot, since most likely both patches go in at the same time, is this change reload/upgrade-compatible? i.e., if an old proxmox-backup(-proxy) process is (still) running that has the lock open with F_SETLK, and the new one obtains it using F_OFD_SETLK, is the behaviour still correct? (the other direction might be interesting too, but can only happen on an unsupported downgrade)
> 
>> The second patch changes the location of the `.lock` file to the `/run/proxmox-backup/locks`
>> tmpfs directory. Like this we don't need to lazy-lock anything and we can keep the lockfile
>> open all the time. Unmounting datastores is now possible as the lock file is not on the
>> datastore mount anymore.
> 
> the same question applies here with the changed path and reloads. if not (and this seems rather likely if the path changes), we might need an explicit hand-over and compat code that obtains both locks at least as long as any old processes are still running?
> 

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.