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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 2768992190 for ; Thu, 1 Feb 2024 09:26:39 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0D0CBB825 for ; Thu, 1 Feb 2024 09:26:39 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 1 Feb 2024 09:26:38 +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 C345D40056 for ; Thu, 1 Feb 2024 09:26:37 +0100 (CET) Message-ID: <265ef5c0-601a-41fc-81e8-ca7f908094b0@proxmox.com> Date: Thu, 1 Feb 2024 09:26:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Friedrich Weber , Proxmox VE development discussion References: <20240111150332.733635-1-f.weber@proxmox.com> <80c410ca-3615-45cc-9801-f1e2d14cab78@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <80c410ca-3615-45cc-9801-f1e2d14cab78@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.073 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 - Subject: Re: [pve-devel] [PATCH storage 0/2] fix #4997: lvm: avoid autoactivating (new) LVs after boot X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2024 08:26:39 -0000 Am 31.01.24 um 16:07 schrieb Friedrich Weber: > Thanks for the review! > > On 26/01/2024 12:14, Fiona Ebner wrote: >>> Some points to discuss: >>> >>> * Fabian and I discussed whether it may be better to pass `-K` and set the >>> "activation skip" flag only for LVs on a *shared* LVM storage. But this may >>> cause issues for users that incorrectly mark an LVM storage as shared, create a >>> bunch of LVs (with "activation skip" flag), then unset the "shared" flag, and >>> won't be able to activate LVs afterwards (`lvchange -ay` without `-K` on an LV >>> with "activation skip" is a noop). What do you think? >>> >> >> Is there a way to prevent auto-activation on boot for LVs on a shared >> (PVE-managed) LVM storage? Also a breaking change, because users might >> have other LVs on the same storage, but would avoid the need for the >> flag. Not against the current approach, just wondering. > > One can also disable autoactivation for a whole VG (i.e., all LVs of > that VG): > > vgchange --setautoactivation n VG > > At least in my tests, after setting this no LV in that VG is active > after boot, so this might also solve the problem. I suppose setting this > automatically for existing VGs would be too dangerous (as users might > have other LVs in that VGs). But our LVM storage plugin *could* set this > when creating a new shared VG [1]? > > Not sure which option is better, though. > Do you still need the -K flag to activate volumes in such a VG? If yes, nothing is gained compared to the more fine-grained "setting it on individual LVs". If no, we could save that. OTOH, users might want to use existing shared VGs and then they would need to apply this setting themselves. >> Guardrails against issues caused by misconfiguration always warrant a >> cost-benefits analysis. What is the cost for also setting the flag for >> LVs on non-shared LVM storages? Or logic needs to be correct either way ;) > > AFAICT, setting this LV flag on non-shared LVM storages doesn't have > negative side-effects. I don't think we rely on autoactivation anywhere. > We'd need to take care of passing `-K` for all our `lvchange -ay` calls, > but AFAICT, `lvchange` calls are only done in the LVM/LvmThin plugins in > pve-storage. > We need to have -K for activations, no matter if we only set the activationskip flag for shared or all. That's not an additional cost.