Bug #42928
closed
ceph-bluestore-tool bluefs-bdev-new-db does not update lv tags
Added by Arthur van Kleef over 4 years ago.
Updated almost 3 years ago.
Description
Adding a DB Device to an existing OSD with ceph-bluestore-tool bluefs-bdev-new-db does not update the lv tags of the OSD with the ceph.db_device and ceph.db_uuid tags.
This causes block.db symlinks to be missing on restart, which prevents the OSD to start.
- Assignee set to Igor Fedotov
Those two tags are missing:
ceph.db_device=/dev/BLOCKDB
ceph.db_uuid=k7Oc64-aShi-Z4Y0-Opov-daQM-Vdue-kJpIAN
is ceph.db_uuid the LVM uuid?
OK i was able to solve this by using the lv tools and copy all lv flags from the block device to db and just chaning the ceph.type from block to db.
Thanks!
Quick question, what if the bluestore device is not an lvm device ? All my devices were created with luminous with ceph-deploy. I added the db device using bluestore, but the osd does not start on reboot ( I have to reset permission on the lvm device ). And I note that there are no rules in usr/lib/udev/rules.d/ anyway.
Any way to determine the correct DB->Block arrangement after they are lost? I have a host that has hit this bug and am trying to recover it.
to answer my question - head -n 2 /dev/vg/lv will give the block device uuid
- Related to Bug #49554: add ceph-volume lvm [new-db|new-wal|migrate] commands added
- Status changed from New to Closed
Complete bluefs volume migration is now implemented at ceph-volume level. See https://github.com/ceph/ceph/pull/39580
ceph-bluestore-tool's migrate command just implements the actual copying and ceph-volume handles LVM tags on its own.
Hence closing this ticket.
- Has duplicate Bug #62593: ceph-bluestore-tool bluefs-bdev-new-db creates block.db symlink to non-persistent /dev/dm-## instead of given and stable /dev/VG_NMAE/LV_NAME path added
Also available in: Atom
PDF