Hi, we have OSD nodes currently consisting of two 605GB SSDs and six 18TB HDDs. The hosts have room for twelve HDDs. We created a drivegroup spec that looks like this: spec: block_db_size: 100GB data_devices: rotational: true size: '18TB:' db_devices: rotational: false size: '550GB:650GB' db_slots: 6 Initially this creates 6 OSDs with their RocksDB+WAL on the SSDs, 3 each which is nice for load balancing. But when we add another HDD it gets a 17.9TB data volume and a 100GB DB volume, both on the HDD: sdm 8:192 0 18T 0 disk ├─ceph--846e1a59--aff6--4ef8--9b71--de7241531677-osd--block--026e8cef--123d--47d9--9b30--211f94edf96c 252:16 0 17.9T 0 lvm └─ceph--846e1a59--aff6--4ef8--9b71--de7241531677-osd--db--88c47d0b--f5c6--4cec--8909--c5f8036ca459 252:17 0 100G 0 lvm I would have assumed that the remaining 305GB on the SSDs would be used. How do we achieve this? Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
Which Ceph release?
On Aug 7, 2025, at 10:18 AM, Robert Sander <r.sander@heinlein-support.de> wrote:
Hi,
we have OSD nodes currently consisting of two 605GB SSDs and six 18TB HDDs. The hosts have room for twelve HDDs.
We created a drivegroup spec that looks like this:
spec: block_db_size: 100GB data_devices: rotational: true size: '18TB:' db_devices: rotational: false size: '550GB:650GB' db_slots: 6
block_db_size and db_slots are meant to be mutually exclusive. The former specifies the size of a slice; the latter says to divide up the device into N even slices. That said, it's not entirely clear that db_slots always works as expected. I would leave it out. What manner of SSD is 605GB?
Initially this creates 6 OSDs with their RocksDB+WAL on the SSDs, 3 each which is nice for load balancing.
But when we add another HDD it gets a 17.9TB data volume and a 100GB DB
Is it the same HDD SKU as existing OSDs? You could be suffering from this new HDD being ever so slightly smaller than the existing HDDs, and from base 2 units (TiB) vs base 10 (TB). Which is likely the same reason you have a size range for the DB device spec. I suggest: set the OSD service to unmanaged thoroughly zap the new HDD until it shows completely empty take out db_slots change the osdspec to size: '15TB:' Then see if you get the results you expect.
volume, both on the HDD:
sdm 8:192 0 18T 0 disk ├─ceph--846e1a59--aff6--4ef8--9b71--de7241531677-osd--block--026e8cef--123d--47d9--9b30--211f94edf96c 252:16 0 17.9T 0 lvm └─ceph--846e1a59--aff6--4ef8--9b71--de7241531677-osd--db--88c47d0b--f5c6--4cec--8909--c5f8036ca459 252:17 0 100G 0 lvm
I would have assumed that the remaining 305GB on the SSDs would be used.
How do we achieve this?
Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin
http://www.heinlein-support.de
Tel: 030 / 405051-43 Fax: 030 / 405051-19
Zwangsangaben lt. §35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, Am 8/7/25 um 16:41 schrieb Anthony D'Atri:
Which Ceph release?
19.2.3
block_db_size and db_slots are meant to be mutually exclusive. The former specifies the size of a slice; the latter says to divide up the device into N even slices. That said, it's not entirely clear that db_slots always works as expected. I would leave it out.
db_slots has absolutely no effect on the outcome.
What manner of SSD is 605GB?
This will be a namespace on a larger NVMe where the rest would be used as OSD. Currently I am testing this on VMs. This is why we can allocate exactly 6* 100GB to that block device.
Initially this creates 6 OSDs with their RocksDB+WAL on the SSDs, 3 each which is nice for load balancing.
But when we add another HDD it gets a 17.9TB data volume and a 100GB DB
Is it the same HDD SKU as existing OSDs? You could be suffering from this new HDD being ever so slightly smaller than the existing HDDs, and from base 2 units (TiB) vs base 10 (TB). Which is likely the same reason you have a size range for the DB device spec.
I do not think that this is the issue here but I'll try. Regards -- Robert Sander Linux Consultant Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: +49 30 405051 - 0 Fax: +49 30 405051 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
Hi, Am 8/7/25 um 16:18 schrieb Robert Sander:
sdm 8:192 0 18T 0 disk ├─ceph--846e1a59--aff6--4ef8--9b71--de7241531677-osd--block--026e8cef--123d--47d9--9b30--211f94edf96c 252:16 0 17.9T 0 lvm └─ceph--846e1a59--aff6--4ef8--9b71--de7241531677-osd--db--88c47d0b--f5c6--4cec--8909--c5f8036ca459 252:17 0 100G 0 lvm
The same happens when I remove an existing OSD with ceph orch osd rm 34 --zap and let the orchestrator recreate it immediately. # ceph osd df tree $(hostname) ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME -5 108.48843 - 108 TiB 601 GiB 950 MiB 17 KiB 840 MiB 108 TiB 0.54 1.00 - host $(hostname) 0 hdd 18.09769 1.00000 18 TiB 100 GiB 158 MiB 1 KiB 241 MiB 18 TiB 0.54 1.00 46 up osd.0 8 hdd 18.09769 1.00000 18 TiB 100 GiB 158 MiB 1 KiB 246 MiB 18 TiB 0.54 1.00 49 up osd.8 16 hdd 18.09769 1.00000 18 TiB 100 GiB 158 MiB 4 KiB 45 MiB 18 TiB 0.54 1.00 41 up osd.16 21 hdd 18.09769 1.00000 18 TiB 100 GiB 158 MiB 5 KiB 46 MiB 18 TiB 0.54 1.00 41 up osd.21 27 hdd 18.09769 1.00000 18 TiB 100 GiB 158 MiB 5 KiB 46 MiB 18 TiB 0.54 1.00 46 up osd.27 34 hdd 18.00000 1.00000 18 TiB 100 GiB 158 MiB 1 KiB 216 MiB 18 TiB 0.54 1.00 51 up osd.34 TOTAL 108 TiB 601 GiB 950 MiB 21 KiB 840 MiB 108 TiB 0.54 MIN/MAX VAR: 1.00/1.00 STDDEV: 0.00 No I have a new OSD on the existing 18TB HDD which is smaller because a 100G DB volume has been created on it. And the SSD now has 100G more space: # pvs PV VG Fmt Attr PSize PFree /dev/sda3 system lvm2 a-- <56.95g 0 /dev/sdb ceph-70008fd1-08b8-4cbc-b8eb-6c5d7168147f lvm2 a-- <605.00g <405.00g /dev/sdc ceph-46b31f42-bd39-48c7-a855-6ca7e722ffe2 lvm2 a-- <605.00g <305.00g /dev/sdf ceph-dc6876b6-ec6b-4486-bf94-f11fe5c6151b lvm2 a-- <18.00t 0 /dev/sdg ceph-3e9d0706-14b9-4344-be98-8d3ba157887b lvm2 a-- <18.00t 0 /dev/sdh ceph-cc6094f5-cd8a-47d9-ab94-d5cc45321cc7 lvm2 a-- <18.00t 0 /dev/sdi ceph-74101368-5145-44c0-8b72-b90160633ac4 lvm2 a-- <18.00t 0 /dev/sdj ceph-aa6188ef-630a-4471-bdd9-71f0ab3228de lvm2 a-- <18.00t 0 /dev/sdk ceph-c5359b20-222a-42eb-924f-3c776d5cd913 lvm2 a-- <18.00t 0 /dev/sdm ceph-846e1a59-aff6-4ef8-9b71-de7241531677 lvm2 a-- <18.00t 0 # lvs LV VG Attr LSize osd-block-1b8e2d04-2664-4c4d-8ef5-db7b3eae70a3 ceph-3e9d0706-14b9-4344-be98-8d3ba157887b -wi-ao---- <18.00t osd-db-2783958b-1663-46dc-8f2a-43d5ed2d756f ceph-46b31f42-bd39-48c7-a855-6ca7e722ffe2 -wi-ao---- 100.00g osd-db-53753101-acda-421b-ac53-8def95f0b92d ceph-46b31f42-bd39-48c7-a855-6ca7e722ffe2 -wi-ao---- 100.00g osd-db-958f9106-1931-4fc8-98cc-a64f29a78ddd ceph-46b31f42-bd39-48c7-a855-6ca7e722ffe2 -wi-ao---- 100.00g osd-db-82ced9d1-aab3-4c9f-b98f-9dd03691334d ceph-70008fd1-08b8-4cbc-b8eb-6c5d7168147f -wi-ao---- 100.00g osd-db-bf25cca1-37b1-4af2-b87b-afeb0296edb1 ceph-70008fd1-08b8-4cbc-b8eb-6c5d7168147f -wi-ao---- 100.00g osd-block-266fbe77-4512-48c1-b80e-28596ffbfc76 ceph-74101368-5145-44c0-8b72-b90160633ac4 -wi-ao---- <18.00t osd-block-71e2bd64-0545-4bd6-86eb-11b4d7d9dde1 ceph-aa6188ef-630a-4471-bdd9-71f0ab3228de -wi-ao---- <18.00t osd-block-5a0af8ec-5dc2-4ad8-8f9d-fdaf7108434b ceph-c5359b20-222a-42eb-924f-3c776d5cd913 -wi-ao---- 17.90t osd-db-e51a1c62-4efa-42ac-818f-33afeda5cc61 ceph-c5359b20-222a-42eb-924f-3c776d5cd913 -wi-ao---- 100.00g osd-block-ccbbcf09-6aa7-4499-94e1-fc00cad41904 ceph-cc6094f5-cd8a-47d9-ab94-d5cc45321cc7 -wi-ao---- <18.00t osd-block-ba721825-178a-4c30-b39b-d71e3611398f ceph-dc6876b6-ec6b-4486-bf94-f11fe5c6151b -wi-ao---- <18.00t This did work better in version 18.2.7 Regards -- Robert Sander Linux Consultant Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: +49 30 405051 - 0 Fax: +49 30 405051 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
Hi, The same situation with Ceph 18.2.7: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 605G 0 disk ├─ceph--2e6edbc5--08b5--4112--b019--00eb77d37be7-osd--db--92f3aa68--5ea9--45f0--9736--1e940e32a694 252:9 0 100G 0 lvm ├─ceph--2e6edbc5--08b5--4112--b019--00eb77d37be7-osd--db--05597602--be0a--4bef--ba6f--00f1fd6a00f8 252:11 0 100G 0 lvm └─ceph--2e6edbc5--08b5--4112--b019--00eb77d37be7-osd--db--cd611225--b826--446d--ac9c--8fbea4c77cce 252:13 0 100G 0 lvm sdc 8:32 0 605G 0 disk ├─ceph--1f1e5a91--6030--4f23--a6c0--793863682798-osd--db--3dbf6581--ddbf--4b97--9bd7--2f3d2e2b4370 252:5 0 100G 0 lvm └─ceph--1f1e5a91--6030--4f23--a6c0--793863682798-osd--db--3930da0a--479f--4e2d--a58a--3404a8add512 252:7 0 100G 0 lvm sdd 8:48 0 2.2T 0 disk sde 8:64 0 2.2T 0 disk sdf 8:80 0 18T 0 disk sdg 8:96 0 18T 0 disk └─ceph--77e27c98--c003--4050--ba1f--2c6b4b3209c6-osd--block--dbd1d26c--72be--4632--82a7--5aabce5f17aa 252:4 0 18T 0 lvm sdh 8:112 0 18T 0 disk └─ceph--a2de7aa4--9ee6--4f2b--ab67--fb0e021c1e86-osd--block--acced776--dec8--4fa6--b946--b9cd8d264f40 252:6 0 18T 0 lvm sdi 8:128 0 18T 0 disk └─ceph--0332a3d4--eeb6--47a4--8fd3--60cb362b2eae-osd--block--25c23ee7--51a8--4113--9c64--5e46a71acc69 252:8 0 18T 0 lvm sdj 8:144 0 18T 0 disk └─ceph--35a572b9--618b--411a--95a5--ffcbcc6909fd-osd--block--d6339590--f5d0--4db8--8f1a--c9fa884f8a05 252:10 0 18T 0 lvm sdk 8:160 0 18T 0 disk └─ceph--d8226699--19af--4845--b0c4--01888eda4f0c-osd--block--cdbb54d3--790e--47eb--b3ee--5a743c820d5a 252:12 0 18T 0 lvm # ceph orch set-managed osd.hdd2025 Set unmanaged to False for service osd.hdd2025 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 605G 0 disk ├─ceph--2e6edbc5--08b5--4112--b019--00eb77d37be7-osd--db--92f3aa68--5ea9--45f0--9736--1e940e32a694 252:9 0 100G 0 lvm ├─ceph--2e6edbc5--08b5--4112--b019--00eb77d37be7-osd--db--05597602--be0a--4bef--ba6f--00f1fd6a00f8 252:11 0 100G 0 lvm └─ceph--2e6edbc5--08b5--4112--b019--00eb77d37be7-osd--db--cd611225--b826--446d--ac9c--8fbea4c77cce 252:13 0 100G 0 lvm sdc 8:32 0 605G 0 disk ├─ceph--1f1e5a91--6030--4f23--a6c0--793863682798-osd--db--9fe6e4c3--5b3c--4d4f--b889--e18e1667d1f3 252:3 0 100G 0 lvm ├─ceph--1f1e5a91--6030--4f23--a6c0--793863682798-osd--db--3dbf6581--ddbf--4b97--9bd7--2f3d2e2b4370 252:5 0 100G 0 lvm └─ceph--1f1e5a91--6030--4f23--a6c0--793863682798-osd--db--3930da0a--479f--4e2d--a58a--3404a8add512 252:7 0 100G 0 lvm sdd 8:48 0 2.2T 0 disk sde 8:64 0 2.2T 0 disk sdf 8:80 0 18T 0 disk └─ceph--da0dacf6--f310--4713--a998--73869949bd07-osd--block--725f73c2--9b15--434e--876a--954823a33373 252:2 0 18T 0 lvm sdg 8:96 0 18T 0 disk └─ceph--77e27c98--c003--4050--ba1f--2c6b4b3209c6-osd--block--dbd1d26c--72be--4632--82a7--5aabce5f17aa 252:4 0 18T 0 lvm sdh 8:112 0 18T 0 disk └─ceph--a2de7aa4--9ee6--4f2b--ab67--fb0e021c1e86-osd--block--acced776--dec8--4fa6--b946--b9cd8d264f40 252:6 0 18T 0 lvm sdi 8:128 0 18T 0 disk └─ceph--0332a3d4--eeb6--47a4--8fd3--60cb362b2eae-osd--block--25c23ee7--51a8--4113--9c64--5e46a71acc69 252:8 0 18T 0 lvm sdj 8:144 0 18T 0 disk └─ceph--35a572b9--618b--411a--95a5--ffcbcc6909fd-osd--block--d6339590--f5d0--4db8--8f1a--c9fa884f8a05 252:10 0 18T 0 lvm sdk 8:160 0 18T 0 disk └─ceph--d8226699--19af--4845--b0c4--01888eda4f0c-osd--block--cdbb54d3--790e--47eb--b3ee--5a743c820d5a 252:12 0 18T 0 lvm As can be seen a third DB volume has been added to sdc and the OSD uses all of the 18TB of sdf. When adding a completely new disk a fourth DB volume gets created on sdb and the new OSD on sdl uses all of the 18TB. Something must have been changed between reef and squid, not for the better. Regards -- Robert Sander Linux Consultant Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: +49 30 405051 - 0 Fax: +49 30 405051 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
Hi, On 08.08.25 15:37, Robert Sander wrote:
As can be seen a third DB volume has been added to sdc and the OSD uses all of the 18TB of sdf.
When adding a completely new disk a fourth DB volume gets created on sdb and the new OSD on sdl uses all of the 18TB.
Something must have been changed between reef and squid, not for the better.
No I changed the drivegroup spec to explicitely name the DB devices: service_type: osd service_id: hdd2025 service_name: osd.hdd2025 placement: label: osd2025 spec: block_db_size: 100GB data_devices: rotational: true size: '16TB:' db_devices: paths: - /dev/sdb - /dev/sdc This still works as expected on 18.2.7: adding a new 18TB HDD adds another DB volume on sdb and a new OSD. On 19.2.3 the orchestrator now does nothing. It does not touch the new HDD (which is listed as available in "ceph orch device ls"). It does not create a DB volume on the HDD (as before) or on the SSD as instructed. The is a real bad regression. With this behaviour of the orchestrator I am not able to recommend Ceph 19 to my customers. Appr half of the run Ceph on HDD with the DB volumes on external drives. Adding or replacing disks becomes a manual task again including creating the DB volumes. This was definitely better in Ceph 18. Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
On 09.08.25 15:29, Robert Sander wrote:
Now I changed the drivegroup spec to explicitely name the DB devices:
service_type: osd service_id: hdd2025 service_name: osd.hdd2025 placement: label: osd2025 spec: block_db_size: 100GB data_devices: rotational: true size: '16TB:' db_devices: paths: - /dev/sdb - /dev/sdc
I have to also list all the data devices by path: service_type: osd service_id: hdd2025 placement: label: osd2025 spec: block_db_size: 100GB data_devices: paths: - /dev/sdf - /dev/sdg - /dev/sdh - /dev/sdi - /dev/sdj - /dev/sdk - /dev/sdl - /dev/sdm db_devices: paths: - /dev/sdb - /dev/sdc This works now on Ceph 19 but it depends on the HDDs having the same drive "letters" on each host. Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
Hi Guillaume, your commit 4941d09 https://github.com/ceph/ceph/commit/4941d098e337f2b7ad8c6f7c90be3ae252d22f7b introduces this bug. Please have a look at https://tracker.ceph.com/issues/72696 Especially the changes to src/ceph-volume/ceph_volume/util/device.py were causing this. After I reverted them I get the expected behaviour. Am 07.08.25 um 4:18 PM schrieb Robert Sander:
we have OSD nodes currently consisting of two 605GB SSDs and six 18TB HDDs. The hosts have room for twelve HDDs.
We created a drivegroup spec that looks like this:
spec: block_db_size: 100GB data_devices: rotational: true size: '18TB:' db_devices: rotational: false size: '550GB:650GB' db_slots: 6
Initially this creates 6 OSDs with their RocksDB+WAL on the SSDs, 3 each which is nice for load balancing.
But when we add another HDD it gets a 17.9TB data volume and a 100GB DB volume, both on the HDD:
sdm 8:192 0 18T 0 disk ├─ceph--846e1a59--aff6--4ef8--9b71--de7241531677-osd-- block--026e8cef--123d--47d9--9b30--211f94edf96c 252:16 0 17.9T 0 lvm └─ceph--846e1a59--aff6--4ef8--9b71--de7241531677-osd--db--88c47d0b-- f5c6--4cec--8909--c5f8036ca459 252:17 0 100G 0 lvm
I would have assumed that the remaining 305GB on the SSDs would be used.
Regards -- Robert Sander Linux Consultant Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: +49 30 405051 - 0 Fax: +49 30 405051 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
Hi, On 10/13/25 13:33, Robert Sander wrote:
Especially the changes to src/ceph-volume/ceph_volume/util/device.py were causing this. After I reverted them I get the expected behaviour.
Attached is a patch to revert to the behaviour from Ceph 18 when dealing with "hybrid" OSDs. Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
Hi, Am 13.10.25 um 1:33 PM schrieb Robert Sander:
your commit 4941d09 https://github.com/ceph/ceph/ commit/4941d098e337f2b7ad8c6f7c90be3ae252d22f7b introduces this bug.
Please have a look at https://tracker.ceph.com/issues/72696
Especially the changes to src/ceph-volume/ceph_volume/util/device.py were causing this. After I reverted them I get the expected behaviour.
An alternative is to adapt the selector in the orchestrator as in this patch: diff -ruN usr.orig/lib/python3.9/site-packages/ceph/deployment/drive_selection/selector.py usr/lib/python3.9/site-packages/ceph/deployment/drive_selection/selector.py --- usr.orig/lib/python3.9/site-packages/ceph/deployment/drive_selection/selector.py 2025-10-15 18:37:52.000000000 +0000 +++ usr/lib/python3.9/site-packages/ceph/deployment/drive_selection/selector.py2025-10-17 08:10:54.840878772 +0000 @@ -78,7 +78,7 @@ # If that is the case, we don't want to count the device # towards the limit as it will already be counted through the # existing daemons - non_ceph_devices = [d for d in devices if not d.ceph_device] + non_ceph_devices = [d for d in devices if not d.ceph_device_lvm] if limit > 0 and (len(non_ceph_devices) + self.existing_daemons >= limit): logger.debug("Refuse to add {} due to limit policy of <{}>".format( @@ -135,14 +135,14 @@ logger.debug('Ignoring disk {} as it is being replaced.'.format(disk.path)) continue - if not disk.available and not disk.ceph_device: + if not disk.available and not disk.ceph_device_lvm: logger.debug( ("Ignoring disk {}. " "Disk is unavailable due to {}".format(disk.path, disk.rejected_reasons)) ) continue - if not disk.available and disk.ceph_device and disk.lvs: + if not disk.available and disk.ceph_device_lvm and disk.lvs: other_osdspec_affinity = '' for lv in disk.lvs: if 'osdspec_affinity' in lv.keys(): diff -ruN usr.orig/lib/python3.9/site-packages/ceph/deployment/inventory.py usr/lib/python3.9/site-packages/ceph/deployment/inventory.py --- usr.orig/lib/python3.9/site-packages/ceph/deployment/inventory.py 2025-10-15 18:37:52.000000000 +0000 +++ usr/lib/python3.9/site-packages/ceph/deployment/inventory.py 2025-10-17 08:11:31.894135171 +0000 @@ -44,7 +44,7 @@ class Device(object): report_fields = [ - 'ceph_device', + 'ceph_device_lvm', 'rejected_reasons', 'available', 'path', @@ -67,7 +67,7 @@ device_id=None, # type: Optional[str] lsm_data=None, # type: Optional[Dict[str, Dict[str, str]]] created=None, # type: Optional[datetime.datetime] - ceph_device=None, # type: Optional[bool] + ceph_device_lvm=None, # type: Optional[bool] crush_device_class=None, # type: Optional[str] being_replaced=None, # type: Optional[bool] ): @@ -80,7 +80,7 @@ self.device_id = device_id self.lsm_data = lsm_data if lsm_data is not None else {} # type: Dict[str, Dict[str, str]] self.created = created if created is not None else datetime_now() - self.ceph_device = ceph_device + self.ceph_device_lvm = ceph_device_lvm self.crush_device_class = crush_device_class self.being_replaced = being_replaced @@ -131,7 +131,7 @@ 'path': self.path if self.path is not None else 'unknown', 'lvs': self.lvs if self.lvs else 'None', 'available': str(self.available), - 'ceph_device': str(self.ceph_device), + 'ceph_device_lvm': str(self.ceph_device_lvm), 'crush_device_class': str(self.crush_device_class), 'being_replaced': str(self.being_replaced) } diff -ruN usr.orig/lib/python3.9/site-packages/ceph/tests/test_disk_selector.py usr/lib/python3.9/site-packages/ceph/tests/test_disk_selector.py --- usr.orig/lib/python3.9/site-packages/ceph/tests/test_disk_selector.py 2025-10-15 18:37:52.000000000 +0000 +++ usr/lib/python3.9/site-packages/ceph/tests/test_disk_selector.py 2025-10-17 08:11:47.641244137 +0000 @@ -568,9 +568,9 @@ # as a ceph_device. /dev/sdb and /dev/sdc are not being used # for OSDs yet. The limit will be set to 2 and the DriveSelection # is set to have 1 pre-existing device (corresponding to /dev/sda) - dev_a = Device('/dev/sda', ceph_device=True, available=False) - dev_b = Device('/dev/sdb', ceph_device=False, available=True) - dev_c = Device('/dev/sdc', ceph_device=False, available=True) + dev_a = Device('/dev/sda', ceph_device_lvm=True, available=False) + dev_b = Device('/dev/sdb', ceph_device_lvm=False, available=True) + dev_c = Device('/dev/sdc', ceph_device_lvm=False, available=True) all_devices: List[Device] = [dev_a, dev_b, dev_c] processed_devices: List[Device] = [] filter = DeviceSelection(all=True, limit=2) Regards -- Robert Sander Linux Consultant Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: +49 30 405051 - 0 Fax: +49 30 405051 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
participants (2)
-
Anthony D'Atri
-
Robert Sander