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

[Fabian Grünbichler]

> Gabriel Goller <g.goller at proxmox.com> hat am 06.12.2023 15:21 CET geschrieben:
> 
>  
> On 12/6/23 15:14, Fabian Grünbichler wrote:
> >> Gabriel Goller <g.goller at proxmox.com> hat am 06.12.2023 14:56 CET geschrieben:
> >> On 12/6/23 14:41, Fabian Grünbichler wrote:
> >>> [..]
> >> Just spoke with Stefan Sterz about this and we will probably
> >> apply/release this with a major version bump (kernel update), so that
> >> the user
> >> is forced to reboot the system (same as with his tmpfs locking series).
> >> I don't think there is another way, because the lockfiles get moved to
> >> another dir. Although F_SETLK and F_OFD_SETLK should be compatible,
> >> so having one process use F_SETLK and another F_OFD_SETLK *should* still
> >> work (don't take my word for it though).
> > that doesn't really help though, unless we also add machinery to detect the missing reboot and block any process-locker-requiring stuff in the new process until it has happened? or we make "set all datastores to read-only or offline" a requirement for upgrading from 3 to 4, instead of optional like for 2 to 3[0]. otherwise even just the time between "postinst of PBS package is called" to "upgrade of whole system is fully done" can be big enough to cause a problem..
> >
> > 0: https://pbs.proxmox.com/wiki/index.php/Upgrade_from_2_to_3#Optional:_Enable_Maintenance_Mode
> That's a good idea.
> Optionally we could also somehow remove the `.lock` file in the 
> datastore and remove the `.create(true)`,
> so that creating the 'old' `.lock` file will fail?
> Although not sure how we would do this...

I don't see that working with the old code still running? and if the old code is not running (anymore), we don't have the problem anyway ;)

> But can we also somehow force the user to have the datastore in a 
> maintenance mode? I guess not...

forcing is hard, but we could both
- make it a required step in the upgrade guide (it's not our fault then if the user didn't follow it ;))
- check in post-inst, print a big fat warning, and *not reload* but just keep the old process running

that way, the user will only get an actual 4.x process running if they manually reload or restart the service(s), or reboot the machine:
- reload could be handled by touching a flag file in tmpfs in postinst if the maintenance-mode pre-requisites are not met, and refusing to reload if it is found (that part could already be added to 3.x if needed)
- restart and reboot are okay, since in both cases the old process is killed/stopped, and no lock path mismatch can happen

still, the other variant with passing a long the "need to double-lock" flag would also not be too complex I think if we don't want to wait that long - postinst touches a flag file in tmpfs before reloading (on the first upgrade from a pre-change version), as long as that file exists the new code uses a compat mode that obtains both old and new lock paths. once the flag file is gone (reboot, or process detects no more old processes are around), the compat code path becomes dead code at runtime, and can be removed altogether with the next major release.