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 B87878C6C for ; Wed, 30 Mar 2022 10:19:52 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A5B52572E for ; Wed, 30 Mar 2022 10:19:22 +0200 (CEST) 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 id 160445722 for ; Wed, 30 Mar 2022 10:19:22 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 784F145BE7 for ; Wed, 30 Mar 2022 10:19:15 +0200 (CEST) Message-ID: <99820a3f-d6f0-b312-c539-65db20585f75@proxmox.com> Date: Wed, 30 Mar 2022 10:19:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Thomas Lamprecht , Proxmox VE development discussion References: <20220328111041.1732567-1-a.lauterer@proxmox.com> <64cc9102-e3c9-ef1e-9e2d-1f64f1e87117@proxmox.com> From: Aaron Lauterer In-Reply-To: <64cc9102-e3c9-ef1e-9e2d-1f64f1e87117@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.030 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) 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 manager 1/2] api: osd: return block devices instead of dm node 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: Wed, 30 Mar 2022 08:19:52 -0000 On 3/29/22 18:05, Thomas Lamprecht wrote: > On 28.03.22 13:10, Aaron Lauterer wrote: >> Returning the block devices is more useful than the device node. The >> device node usually points to the DM device for bluestore OSDs: >> /dev/dm-x >> >> In almost all situations one will be interested in the physical device >> underneath, /dev/sdX or /dev/nvmeXnY. In the rare case that someone >> isn't, then one can get a lot of more information by running >> `ceph osd metadata `. >> >> Signed-off-by: Aaron Lauterer >> --- >> PVE/API2/Ceph/OSD.pm | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/PVE/API2/Ceph/OSD.pm b/PVE/API2/Ceph/OSD.pm >> index 93433b3a..c3d1384e 100644 >> --- a/PVE/API2/Ceph/OSD.pm >> +++ b/PVE/API2/Ceph/OSD.pm >> @@ -143,9 +143,9 @@ __PACKAGE__->register_method ({ >> if ($e->{type} eq 'osd' && $osdmd) { >> if ($osdmd->{bluefs}) { >> $new->{osdtype} = 'bluestore'; >> - $new->{blfsdev} = $osdmd->{bluestore_bdev_dev_node}; >> - $new->{dbdev} = $osdmd->{bluefs_db_dev_node}; >> - $new->{waldev} = $osdmd->{bluefs_wal_dev_node}; >> + $new->{blfsdev} = $osdmd->{bluestore_bdev_devices}; >> + $new->{dbdev} = $osdmd->{bluefs_db_devices}; >> + $new->{waldev} = $osdmd->{bluefs_wal_devices}; >> } else { >> $new->{osdtype} = 'filestore'; >> } > > > "device_ids" (e.g.: "sdb=HGST_HDN724040ALE640_PK2334PEGNVD6T") could be also interesting, > but probably separately as its a bit longer but still, could avoid a extra shell lookup. "device_ids" will contain a list of all devices used. With a bit of additional logic we could match that against the different devices to determine which is the bluestore, db and wal device and show the second identifier in a tooltip or so. I would add that as new return values, keeping in mind your other response about changing that one property too much. > > For the UI patch: do we want to hint when the db/wal is on the OSD itself as fallback? Hmm, let me think and try it out how we can not clutter up that view but still convey the info. There are a few ways this could be in reality. If no DB or WAL is set, both are on the bluestore/OSD dev. If a DB dev is set, but no WAL, then the WAL is on the DB dev. If no DB dev is set, but a WAL, then the DB should be on the OSD.