From: Gabriel Goller <g.goller@proxmox.com>
To: "Fabian Grünbichler" <f.gruenbichler@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:21:53 +0100 [thread overview]
Message-ID: <9696737a-6235-4f9f-92ac-f92418dba4ed@proxmox.com> (raw)
In-Reply-To: <695531623.1949.1701872060137@webmail.proxmox.com>
On 12/6/23 15:14, Fabian Grünbichler wrote:
>> 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:
>>> [..]
>> 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...
But can we also somehow force the user to have the datastore in a
maintenance mode? I guess not...
next prev parent reply other threads:[~2023-12-06 14:22 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
2023-12-06 14:21 ` Gabriel Goller [this message]
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=9696737a-6235-4f9f-92ac-f92418dba4ed@proxmox.com \
--to=g.goller@proxmox.com \
--cc=f.gruenbichler@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.