Ceph » ceph-volume

I am not sure I follow why is it advisable to create a partition

The downside is the implementation and management of said partitioning.
It is one other thing needed in all the management of LVs, like
zapping, creating VGs and LVs etc...

I don't know what disk tools report the device empty, the ones we use in ceph-volume (lsblk and blkid) both report usage correctly:

(tmp) root@node9:/home/vagrant# lsblk /dev/sdi
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdi    8:128  0 10.8G  0 disk
(tmp) root@node9:/home/vagrant# lsblk /dev/nvme0n1
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0    0  100G  0 disk
(tmp) root@node9:/home/vagrant# fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

(tmp) root@node9:/home/vagrant# ceph-volume lvm batch /dev/sdi /dev/nvme0n1

Total OSDs: 1

Solid State VG:
  Targets:   block.db                  Total size: 99.00 GB
  Total LVs: 1                         Size per LV: 99.00 GB
  Devices:   /dev/nvme0n1

  Type            Path                                                    LV Size         % of device
----------------------------------------------------------------------------------------------------
  [data]          /dev/sdi                                                9.00 GB         100%
  [block.db]      vg: vg/lv                                               99.00GB        100%
--> The above OSDs would be created if the operation continues
--> do you want to proceed? (yes/no) y
,,,,
--> ceph-volume lvm activate successful for osd ID: 16
--> ceph-volume lvm create successful for: ceph-block-875fd2df-20ce-429f-b6b3-b2
0eefba0bbb/osd-block-c9f4cc59-981f-4e6f-a0e5-6b19e7ff2843
(tmp) root@node9:/home/vagrant# lsblk /dev/nvme0n1
NAME
                                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1
                                      259:0    0  100G  0 disk
└─ceph--block--dbs--ec04f0c3--3e78--4ebc--bc66--e94e4cdaf619-osd--block--db--00b
88b8c--a593--40dc--bbf3--e0cdcbc64ca0 252:4    0   99G  0 lvm
(tmp) root@node9:/home/vagrant# blkid /dev/nvem0n1
(tmp) root@node9:/home/vagrant# blkid /dev/nvme0n1
/dev/nvme0n1: UUID="9Fh6RW-N6s0-buez-XCFk-eEOK-XHcW-vW5r31" TYPE="LVM2_member" 
(tmp) root@node9:/home/vagrant# blkid /dev/sdi
/dev/sdi: UUID="8vyNrS-gK2N-gEw5-5kLW-frFs-9WYC-XadaQj" TYPE="LVM2_member" 
(tmp) root@node9:/home/vagrant# lsblk /dev/sdi
NAME
                             MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdi
                               8:128  0 10.8G  0 disk
└─ceph--block--875fd2df--20ce--429f--b6b3--b20eefba0bbb-osd--block--c9f4cc59--98
1f--4e6f--a0e5--6b19e7ff2843 252:3    0   10G  0 lvm

wow...sorry I think I hit the wrong button...didn't mean to edit Alfredos comment.

ok I think I fixed it...my apologies

Alfredo Deza wrote:

I don't know what disk tools report the device empty, the ones we use in ceph-volume (lsblk and blkid) both report usage correctly:

(tmp) root@node9:/home/vagrant# lsblk /dev/sdi
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdi    8:128  0 10.8G  0 disk
(tmp) root@node9:/home/vagrant# lsblk /dev/nvme0n1
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0    0  100G  0 disk
(tmp) root@node9:/home/vagrant# fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

This is exactly the problem. This is indistinguishable from an empty unused disk.

Also
http://tldp.org/HOWTO/LVM-HOWTO/initdisks.html
and
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/LVM_components.html#multiple_partitions

Though admittedly the second link does not apply here.

I think adding a partition is just a safety measure against instances of fast admin fingers, while costing not much overhead.

There is no need to support multiple partitions (like you mentioned), and it does create an overhead:

• another layer of detection is needed for any operation (whereas it isn't needed today)
• a correlation of device to partition name would need to happen always
• the above two items would increase the surface for problems in code that works well today

Lastly, the initial design of ceph-volume was to leave the creation of LVs up to the user. That idea is still good today for anything that ceph-volume does that doesn't quite
adhere to what an admin might want. If an admin would like to have partitions used in the underlying LV, it is certainly an acceptable thing to do today with ceph-volume, with
no changes required.

If the way ceph-volume is creating LVs might cause some issue for an admin that is not paying close attention, it doesn't warrant the addition of another layer for LV creation, increasing an
already complex task