Pass the checked device nodes to the OSD in vitastor-disk exec-osd #110

Open
koolkhel wants to merge 2 commits from koolkhel/vitastor:exec-osd-real-devices into master
Contributor

Description

Two fixes to vitastor-disk exec-osd; the second one's test needs the first.

  1. Fix --osd-binary option. Command-line options are stored with dashes replaced by underscores, so options["osd-binary"] was never set and exec-osd always ran vitastor-osd.
  2. Pass the checked device nodes to the OSD. exec-osd validated the superblock through the given device but forwarded the by-partuuid paths from it, and vitastor-osd opened whatever those links pointed to by then. With dm-multipath the link moves from the path partition to the dm partition in between, so the OSD opened a node other than the one checked. Forward the real_*_device nodes resolved by read_osd_superblock instead; an empty meta/journal device stays empty, and /info/osd/N already stores the realpath.

Tested: new tests/test_disk_exec_osd.sh — fails on master with "exec-osd did not run the --osd-binary", and with only the first commit with "exec-osd passed the superblock's link instead of the checked device"; passes with both.

Contributor Name

Yury Luneff (MIND Software LLC, https://mindsw.io)

CLA

### Description Two fixes to `vitastor-disk exec-osd`; the second one's test needs the first. 1. **Fix --osd-binary option.** Command-line options are stored with dashes replaced by underscores, so `options["osd-binary"]` was never set and exec-osd always ran vitastor-osd. 2. **Pass the checked device nodes to the OSD.** exec-osd validated the superblock through the given device but forwarded the by-partuuid paths from it, and vitastor-osd opened whatever those links pointed to by then. With dm-multipath the link moves from the path partition to the dm partition in between, so the OSD opened a node other than the one checked. Forward the `real_*_device` nodes resolved by `read_osd_superblock` instead; an empty meta/journal device stays empty, and `/info/osd/N` already stores the realpath. Tested: new `tests/test_disk_exec_osd.sh` — fails on master with "exec-osd did not run the --osd-binary", and with only the first commit with "exec-osd passed the superblock's link instead of the checked device"; passes with both. ### Contributor Name Yury Luneff (MIND Software LLC, https://mindsw.io) ### CLA - [x] I accept Vitastor CLA agreement: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md
koolkhel added 2 commits 2026-10-26 21:08:25 +03:00
Command-line options are stored with dashes replaced by underscores, so
options["osd-binary"] was never set and exec-osd always ran vitastor-osd.
exec-osd validated the superblock through the given device but forwarded
the by-partuuid paths from it, and vitastor-osd opened whatever those links
pointed to by then. With dm-multipath the link moves from the path partition
to the dm partition in between, so the OSD opened a node other than the one
checked. Forward the real_*_device nodes resolved by read_osd_superblock
instead.
Owner

Тут х-з. Меня такой вариант смущает. Кейс под который ты это фиксишь очень узкий, запуск OSD поверх dm-multipath это же всё-таки извращение. Плюс не может ли там так оказаться что у тебя будет 3 раза один и тот же девайс в системе: путь 1, путь 2 и сам multipath? Если так может быть, то может быть лучше в этом кейсе как-то научиться фильтровать эти девайсы, отдельным правилом udev мб например?

Тут х-з. Меня такой вариант смущает. Кейс под который ты это фиксишь очень узкий, запуск OSD поверх dm-multipath это же всё-таки извращение. Плюс не может ли там так оказаться что у тебя будет 3 раза один и тот же девайс в системе: путь 1, путь 2 и сам multipath? Если так может быть, то может быть лучше в этом кейсе как-то научиться фильтровать эти девайсы, отдельным правилом udev мб например?
Owner

Что собственно смущает, смущает что (допустим) если глюканёт рейд контроллер и между exec-osd и запуском osd поменяются /dev/sda на /dev/sdb, то мы с этим фиксом можем запустить OSD на чужом диске. Учитывая этот риск и узость кейса, есть смысл подумать о другом варианте фикса

Что собственно смущает, смущает что (допустим) если глюканёт рейд контроллер и между exec-osd и запуском osd поменяются /dev/sda на /dev/sdb, то мы с этим фиксом можем запустить OSD на чужом диске. Учитывая этот риск и узость кейса, есть смысл подумать о другом варианте фикса
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u exec-osd-real-devices:koolkhel-exec-osd-real-devices
git checkout koolkhel-exec-osd-real-devices
Sign in to join this conversation.
No Reviewers
No Label
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vitalif/vitastor#110
No description provided.