public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Gabriel Goller <g.goller@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox v2] sys: open process_locker lockfile lazy
Date: Fri, 1 Dec 2023 11:15:11 +0100	[thread overview]
Message-ID: <e54e4059-b30f-48f5-9f83-4171feec7d1c@proxmox.com> (raw)
In-Reply-To: <8ba8aef7-b595-4c52-9bb9-4243a739b595@proxmox.com>

On 11/28/23 11:04, Thomas Lamprecht wrote:
> [..]
> I never had good experience with lazy open (or lazy unmount) so I'd like
> to avoid such things if possible.
> And luckily we already have a proposed solution, one that just gathered
> a bit dust and where only bikeshedding questions where discussed anymore,
> namely the "refactor datastore locking to use tmpfs" [0] one from Stefan
> Sterz.
>
> As with that we have a few advantages:
> - no lazy opening code that needs lots of brain power to ensure it really
>    is OK
>
> - all special FS (like NFS) profit from this change too, that was even
>    the original reason for the series.
>
> - should be a bit faster to have locks in memory only
>
> - the issue with unmount goes away too
>
> The only potential disadvantage:
>
> - locks are lost over (sudden) reboots, but should not matter really as
>    we're mostly locking for concurrency, but still write data safely, i.e.,
>    to tmpfile and then rename, so the on-disk state should always be
>    consistent anyway.
>
> Maybe you can check with Stefan how the status is, and maybe take over
> his series, rebase it and see if we can get the final nits sorted out.
>
> [0]: https://lists.proxmox.com/pipermail/pbs-devel/2022-August/005414.html
That's a good idea!
We could move the process-locker lock files (currently they are in 
`/mnt/datastore{name}/.lock`)
to the tmpfs directory where all the other locks are (probably 
`/run/proxmox-backup/{name}/.lock`.

Like this we don't have to do the lazy-locking, because the file can be 
open all the time and we
can still unmount the datastore (as the lockfile is not on that mount 
anymore).

This change could also be applied without @sterzy's series.




  reply	other threads:[~2023-12-01 10:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-15 14:31 Gabriel Goller
2023-11-28 10:04 ` Thomas Lamprecht
2023-12-01 10:15   ` Gabriel Goller [this message]
2023-12-04 13:23     ` Gabriel Goller

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=e54e4059-b30f-48f5-9f83-4171feec7d1c@proxmox.com \
    --to=g.goller@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=t.lamprecht@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal