Yes I have filed a tracker for the issue: http://tracker.ceph.com/issues/23645 On Tue, Apr 10, 2018 at 9:57 AM, Aleksey Gutikov <aleksey.gutikov@xxxxxxxxxx> wrote: > Sata hdds, this happen on running server, without reboot. > Due to hardware problem, vibration, human factor, anything, sata host loose > connection with drive and /dev/sda disappears. Than operator unplug/plug it > and without lvm it can appear with same node /dev/sda and with different > one, it does not matrer - osd will be started. > But in case of lvm /dev/dm-0 holds lvm objects and sda node, so disk got > next letter (/dev/sdt for example), but lvm can't create lv with same uid, > so lsblk does not see logical volume on this disk > Yes everything will be fixed after reboot, but I don't think it is a > solution. > > On Apr 10, 2018 6:56 PM, "Vasu Kulkarni" <vakulkar@xxxxxxxxxx> wrote: > > On Tue, Apr 10, 2018 at 7:19 AM, Aleksei Gutikov > <aleksey.gutikov@xxxxxxxxxx> wrote: >> >> Hi all, >> >> Previously with ceph-disk when hdd flaps there was udev rule starting >> "ceph-disk trigger" that was checking xfs partition with osd metadata and >> staring osd if metadata exists. >> >> Now with ceph-volume device mapper device (/dev/dm-8 for example) hold the >> whole tree of kernel objects including lvm lv, vg and pv and also block >> device itself so same disk appears with different letter and without lvm >> data (lsblk does not see lv on disk with different letter). >> >> And I have to perform a list of manual actions to start osd: >> >> - remove device mapper device: >> sudo dmsetup remove /dev/dm-8 >> >> - disable new block device and rescan scsi to make lvm volume appear: >> echo 1 | sudo tee /sys/block/sdb/device/delete >> echo "- - -" | sudo tee /sys/class/scsi_host/host0/scan >> >> - maybe umount osd direcroty (I'm not sure if it is required): >> sudo umount /var/lib/ceph/osd/ceph-12 >> >> - list osd disks to get lv name (osd fsid): >> sudo ceph-volume lvm list >> >> - And finally start osd: >> sudo ceph-volume lvm trigger 12-92b66a98-1c35-40a8-bf5b-ac123c366166 >> >> >> Is that expected behavior or a bug or I'm missing something? > > > What you are saying is a bug and you should file a tracker, > ceph-volume should handle the change internally and there is no need > for admin > to do above operation for any dev mapper name changes. Are these > external scsi devices ? > > >> >> Thanks >> >> -- >> >> Best regards, >> Aleksei Gutikov >> Software Engineer | synesis.ru | Minsk. BY >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html