In my side, I saw the osd container trying to map and start on another "device
mapper" that in "READ-ONLY". You could check by
Step 1: check the folder store OSD infomation
the path is /var/lib/ceph/{fsid}/osd.{id}/block , when we run `ls -lah {block}` , we will
get a symlink like that
=========
ls -l /var/lib/ceph/3ff9ccd4-7f54-11eb-99eb-73dea97d4515/osd.55/block
lrwxrwxrwx 1 ceph ceph 93 Jun 12 21:42
/var/lib/ceph/3ff9ccd4-7f54-11eb-99eb-73dea97d4515/osd.55/block ->
/dev/mapper/osprober-linux-ceph--e0f80117--76b3--410d--b980--5ddf6a40c582-osd--block--dff698e2--020e--4986--9911--869b898baa5a
=========
Step 2 : check the state of this device from dmsetup
run `dmsetup ls --tree | grep "e0f80117"` , we'll have a group of device map
for same hard drive but the state one of them (osdprober) was read-only
dmsetup info
osprober-linux-ceph--e0f80117--76b3--410d--b980--5ddf6a40c582-osd--block--dff698e2--020e--4986--9911--869b898baa5a
==> to solve this issue we can `dmsetup remove
osprober-linux-ceph--e0f80117--76b3--410d--b980--5ddf6a40c582-osd--block--dff698e2--020e--4986--9911--869b898baa5a`
to remove the orphaned dm device and start OSD again