From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 D3C81B8D49 for ; Wed, 6 Dec 2023 15:22:25 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id AE93E3010 for ; Wed, 6 Dec 2023 15:21:55 +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 ; Wed, 6 Dec 2023 15:21:54 +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 0AC6F425EE for ; Wed, 6 Dec 2023 15:21:54 +0100 (CET) Message-ID: <9696737a-6235-4f9f-92ac-f92418dba4ed@proxmox.com> Date: Wed, 6 Dec 2023 15:21:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= , Proxmox Backup Server development discussion References: <20231206132834.240700-1-g.goller@proxmox.com> <1764237283.1899.1701870086441@webmail.proxmox.com> <2507e464-7b0a-4814-b089-dc5b1d8d2904@proxmox.com> <695531623.1949.1701872060137@webmail.proxmox.com> From: Gabriel Goller In-Reply-To: <695531623.1949.1701872060137@webmail.proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.156 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 v2 proxmox{, -backup} 0/2] Move ProcessLocker to tmpfs X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2023 14:22:25 -0000 On 12/6/23 15:14, Fabian Grünbichler wrote: >> Gabriel Goller 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...