From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Gabriel Goller <g.goller@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH v2 proxmox{, -backup} 0/2] Move ProcessLocker to tmpfs
Date: Wed, 6 Dec 2023 15:14:20 +0100 (CET) [thread overview]
Message-ID: <695531623.1949.1701872060137@webmail.proxmox.com> (raw)
In-Reply-To: <2507e464-7b0a-4814-b089-dc5b1d8d2904@proxmox.com>
> Gabriel Goller <g.goller@proxmox.com> hat am 06.12.2023 14:56 CET geschrieben:
> On 12/6/23 14:41, Fabian Grünbichler wrote:
> >>
> >> Gabriel Goller <g.goller@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)
> >
> 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
next prev parent reply other threads:[~2023-12-06 14:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 13:28 Gabriel Goller
2023-12-06 13:28 ` [pbs-devel] [PATCH v2 proxmox 1/2] process_locker: use ofd locking Gabriel Goller
2023-12-06 13:28 ` [pbs-devel] [PATCH v2 proxmox-backup 2/2] datastore: store datastore lock on tmpfs Gabriel Goller
2023-12-06 13:41 ` [pbs-devel] [PATCH v2 proxmox{, -backup} 0/2] Move ProcessLocker to tmpfs Fabian Grünbichler
2023-12-06 13:56 ` Gabriel Goller
2023-12-06 14:14 ` Fabian Grünbichler [this message]
2023-12-06 14:21 ` Gabriel Goller
2023-12-06 14:33 ` Fabian Grünbichler
2023-12-06 14:36 ` Thomas Lamprecht
2023-12-06 14:46 ` Gabriel Goller
2023-12-06 14:58 ` Thomas Lamprecht
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=695531623.1949.1701872060137@webmail.proxmox.com \
--to=f.gruenbichler@proxmox.com \
--cc=g.goller@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 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.