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 2336FC0B57 for ; Fri, 12 Jan 2024 11:06:09 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0C9D61F70B for ; Fri, 12 Jan 2024 11:06:09 +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 ; Fri, 12 Jan 2024 11:06:07 +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 B96C345260 for ; Fri, 12 Jan 2024 11:06:07 +0100 (CET) Message-ID: <5970d7e6-ec71-4484-9f59-339f8c1aadcd@proxmox.com> Date: Fri, 12 Jan 2024 11:06:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: pve-devel@lists.proxmox.com References: <20240111165826.804669-1-f.weber@proxmox.com> <1705047462.e8upimiin2.astroid@yuna.none> From: Friedrich Weber In-Reply-To: <1705047462.e8upimiin2.astroid@yuna.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.101 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. [lvmplugin.pm] Subject: Re: [pve-devel] [PATCH storage] lvm: avoid warning due to human-readable text in vgs output 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: Fri, 12 Jan 2024 10:06:09 -0000 On 12/01/2024 10:22, Fabian Grünbichler wrote: >> --- a/src/PVE/Storage/LVMPlugin.pm >> +++ b/src/PVE/Storage/LVMPlugin.pm >> @@ -130,6 +130,9 @@ sub lvm_vgs { >> >> my ($name, $size, $free, $lvcount, $pvname, $pvsize, $pvfree) = split (':', $line); >> >> + # skip human-readable messages that vgs occasionally prints to stdout >> + return if !defined($size); >> + > > we might want to either log this message (like anything printed to > STDERR), so that the admin at least can notice something weird is going > on, The vgs message is printed to stdout, so we could do something like warn $line if !defined($size); ? > or pass '-qq' to switch `vgs` into silent mode where no such > messages will be printed - although for the latter variant we might want > to check what (else) gets suppressed ("log_print_unless_silent").. True. As discussed in the other subthread with Fiona, `-qq` will also silently answer any prompts with 'no', but it does seem unlikely that `vgs` ever prompts. So passing `-qq` might be an okay option. > AFAICT this message only gets printed if the archives grew very big, and > the backup file does not exist? at least for me using your reproducer, > it's only printed once, and I have to rename rename rm again afterwards > to get it to show up again, which would mean it's not too bad to log it > (as long as it doesn't confuse our code). For the user in enterprise support I mentioned in the commit message, the warnings were logged to the journal by pvestatd every few seconds (without any manual deletion of backup files or similar). I'd need to look at the source again to be sure, but IIRC the message is also printed if the backup exists but is outdated (and the archives are very big). And because LVM got confused by the duplicate VG names, this situation seemed to occur every few seconds. Another complication I forgot about: For that user, /etc/lvm/archive had 800000 files amounting to >1GiB, which also slowed down `vgs -o vg_name` considerably (to >10s), presumably because `vgs -o vg_name` read all those files. But unexpectedly, as soon as `-o` included `pv_name` the command was fast again, presumably because it does not do the reads. So I was considering to modify `sub lvm_vgs` to always include `-o pv_name` in the command (not only if $includepvs is true), but was unsure if the edge case warranted this (somewhat weird) workaround. > the `lvmscan` endpoint also picks up the line btw, which means it ends > up being included in the "VG" selector on the web UI when adding an LVM > storage ;) Hah, fun :) By the way, the message also causes `vgs` to print invalid JSON: # rm -f /etc/lvm/backup/spam ; vgs -o vg_name -q --reportformat json 2>/dev/null { "report": [ Consider pruning spam VG archive with more then 8 MiB in 8305 files (check archiving is needed in lvm.conf). { "vg": [ {"vg_name":"pve"}, {"vg_name":"spam"}, {"vg_name":"testvg"} ] } ] } Dominik suggested that this very much looks like an LVM bug, so I'll check whether it still happens on latest upstream LVM and, if yes, file a bug report there.