ceph-disk relies on partitions (sometimes with magic type IDs) and a stub XFS filesystem, which is more complexity than ceph-volume.
Really, ceph-volume is better. You create an LVM PV/VG/LV (which is completely standard, well supported Linux stuff) on your OSD drive and then pass it to ceph-volume. It puts the OSD metadata in LVM metadata (no stub partition! No XFS!), and the actual OSD directory just gets mounted as a tmpfs and populated from that data. Only one LV for the BlueStore block device. It all just works, and is much easier to reason about than the partitioning stuff with ceph-disk.
Plus you can play around with multiple OSDs on the same device, or OSDs plus system volumes, or RAID members, or anything. I used to have to do some horrible stuff to get somewhat "interesting" Ceph setups with e.g. a system volume on a small RAID next to the OSDs on the same disks, with ceph-disk. All that just works without any confusion with ceph-volume, just make more LVs. Bog standard stuff.
Really, ceph-volume is better. You create an LVM PV/VG/LV (which is completely standard, well supported Linux stuff) on your OSD drive and then pass it to ceph-volume. It puts the OSD metadata in LVM metadata (no stub partition! No XFS!), and the actual OSD directory just gets mounted as a tmpfs and populated from that data. Only one LV for the BlueStore block device. It all just works, and is much easier to reason about than the partitioning stuff with ceph-disk.
Plus you can play around with multiple OSDs on the same device, or OSDs plus system volumes, or RAID members, or anything. I used to have to do some horrible stuff to get somewhat "interesting" Ceph setups with e.g. a system volume on a small RAID next to the OSDs on the same disks, with ceph-disk. All that just works without any confusion with ceph-volume, just make more LVs. Bog standard stuff.