From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <g.goller@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id BE4C8B4327
for <pbs-devel@lists.proxmox.com>; Fri, 1 Dec 2023 11:15:13 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 9FC8A14FC5
for <pbs-devel@lists.proxmox.com>; Fri, 1 Dec 2023 11:15:13 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pbs-devel@lists.proxmox.com>; Fri, 1 Dec 2023 11:15:12 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id A66E74357D
for <pbs-devel@lists.proxmox.com>; Fri, 1 Dec 2023 11:15:12 +0100 (CET)
Message-ID: <e54e4059-b30f-48f5-9f83-4171feec7d1c@proxmox.com>
Date: Fri, 1 Dec 2023 11:15:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>
References: <20231115143158.217714-1-g.goller@proxmox.com>
<8ba8aef7-b595-4c52-9bb9-4243a739b595@proxmox.com>
Content-Language: en-US
From: Gabriel Goller <g.goller@proxmox.com>
In-Reply-To: <8ba8aef7-b595-4c52-9bb9-4243a739b595@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.168 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
T_SCC_BODY_TEXT_LINE -0.01 -
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [proxmox.com]
Subject: Re: [pbs-devel] [PATCH proxmox v2] sys: open process_locker
lockfile lazy
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Fri, 01 Dec 2023 10:15:13 -0000
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.