Mon, Oct 24, 2016 at 16:16:48, eugen wrote about "Re: [freebsd] /dev/ada*p*
или /dev/diskid/DISK-${id}p*?":
> >>> У меня нет над ними ничего вообще. Это просто два диска.
> >> А причем тогда fstab?
> > При том, что присутствует или /dev/ada1p1, или
> > /dev/diskid/DISK-S1E2D7FYp1, но не одновременно.
> > И если в fstab записан один, а GEOM выставила другой - загрузка
> > ломается.
> Погоди-погоди, или над дисками (над GEOM DISK) "нет ничего вообще",
> включая GEOM_PART_*, или есть разделы. Одно из двух.
Разделы не над дисками, а в них. Давай таки более привычными понятиями :)
И я имел в виду то, что ничего сам над ними не строил, никаких
зеркал и т.п.
> Не забываем про GEOM DISK, именно он вынимает серийный номер из диска
> и засовывает его в атрибут GEOM::ident, откуда GEOM LABEL его берет
> для генерации diskid:
>
> # geom disk status | grep ada[12]
> ada1 N/A N/A
> ada2 N/A N/A
> # geom disk list ada2 | grep ident
> ident: WD-WCAWFA251128
Вот не поверишь - мне пофиг, кто его извлекает.
(А не пофиг то, что мы имеем слабопрозрачный механизм с громоздкой
собственной логикой, которая нетривиальна и контринтуитивна (одно
только соотношение понятий provider и consumer, которое прямо
противоречит POLA), и который, как мы видим, начал жить собственной
жизнью. При этом всём он не обеспечивает тривиальную функциональность,
которая по состоянию на сейчас должна быть базовой и безусловно
доступной - я имею в виду _одновременное_ представление объектов как
по иерархии подключения, так и по уникальным идентификаторам.
Но это, конечно, уже из области сакрального плача.)
> >> Если "просто два диска" без разметки, понимаемой
> >> GEOM_PART_*, то никакой GEOM и не занимает диски и не мешает созданию
> >> diskid,
> >> тогда это штатное поведение системы. Если после этого нечто вроде ZFS
> >> откроет diskid, то ada* пропадут. Так и задумано.
> >
> > В данном случае я вообще привёл id _свопа_. Никакой ZFS тут не
> > участвует.
>
> Неважно, своп тоже открывается ядром при выполнении swapon, та же хрень.
Если механизм "открыли по diskid - пропало по иерархии подключения"
работает, как ты описал, то он сработал не на этом уровне, а на уровне
всего диска. При этом появились /dev/ada1p${X} и пропали
/dev/diskid/DISK-${ID}p${X} _все одновременно_. Или, наоборот, с
точностью до обмена местами. На идентичном конфиге, идентичной кроме
patchlevel версии системы, и идентичных опциях загрузки.
Вот теперь, если ты понимаешь этот механизм изнутри, попробуй
предположить, где же оно такое происходит.
> > Но такое же происходит и с двумя соседними UFS разделами,
> > причём со всеми одновременно - у ada1 или появляются p1, p2...,
> > или у serialʼа диска появляются подзаписи p1, p2... в diskid.
>
> Появляется всё, просто diskid пропадает в момент монтирования.
> Или пропадает ada* при открытии diskid. Или ada* не появляется,
> потому что кто-то собрал ядро вообще без GEOM_PART_*
Ещё раз: состав опций GEOM не менялся между вариантами. Кроме того, он
в точности совпадает с GENERIC. "Кто-то" в состоянии проконтролировать
эти детали и начинает уже открытым текстом удивляться, почему второй
"кто-то" этому не верит.
> > А, значит, по сравнению с тем, что ты говоришь - кто-то таки мешает
> > созданию diskids, причём для всего диска.
>
> Я же показал, что diskid не видно просто потому, что соответствующие
> объекты заняты геомами PART_*
Гипотеза не проходит. Картина с конкретным присутствием только одного из
вариантов видна в полном составе уже на момент загрузки в single user
до подключения любых объектов со второго диска. Корень находится на
ada0, своп не активирован, ZFS не активирован, клиентов (в нормальном
смысле) ни на что на ada1 ещё нет. По-твоему, при этом должны были
быть видны оба набора объектов в /dev/, так?
> >> Упомянутый loader tunnable запрещает создание diskid полностью.
> >> Скорее всего, тебе надо его выставить в ноль и расслабиться.
> >
> > Я, наоборот, предпочёл бы видеть, как будто он всегда в 1, а лучше в 2
> > (чтобы присутствовали оба варианта). :)
>
> Оба одновременно при открытых провайдерах на фре не бывает afaik.
При открытых, гм, "провайдерах". Вот я и говорю - похоже, что или
"провайдер" GPT хватает диск раньше, создавая /dev/ada1p${X}, или
label делает это раньше, создавая свои id.
Ты же описываешь в своём примере параллельность работы label к
остальным. Это при том, что у меня
kern.features.geom_label: 1
kern.geom.label.disk_ident.enable: 1
kern.geom.label.gptid.enable: 1
kern.geom.label.gpt.enable: 1
А вот что интересно, кстати. Если посмотреть сейчас чуть по другому
пути:
$ ls -l /dev/gptid
total 0
crw-r----- 1 root operator 0x71 Oct 23 19:04
2ab4dce7-497b-11e3-aa6e-902b34773338
этот uuid виден у ada1p3. Который занят внутри ZFS. Это не к тому, что
он виновник такого переключения - ZFS загружается уже из rc-скриптов,
то есть позже появления эффекта. Почему подключение к ZFS не убирает
его из видимости?
Я отмонтировал ada1p4, картина изменилась:
# ls -l /dev/gptid
total 0
crw-r----- 1 root operator 0x71 Oct 23 19:04
2ab4dce7-497b-11e3-aa6e-902b34773338
crw-r----- 1 root operator 0xc1 Oct 25 05:48
3678df22-69a6-11e3-90e2-902b34773338
примонтировал - снова виден только 2ab4...
Будет ли раздел одновременно виден через иерархию подключения
(ada1p${X}) и gptid? Конфликтуют ли между собой diskid и gptid, будут
ли они оба присутствовать? И будут ли присутствовать, в идеале, все
три, пока ни один не подключен?
> >>> Ага. То есть может быть race?
> >>
> >> Не думаю, ни разу не видел race в GEOM, там всё детерминировано,
> >> хотя и не очевидным образом. У разных GEOM разные свойства - кто-то
> >> захватывает диск эксклюзивно, кто-то нет; кто-то получает его на
> >> "обнюхивание"
> >> (taste) раньше, кто-то позже.
> >
> > Тем не менее, что-то там работает неустойчиво.
> > На текущей загрузке есть, например, /dev/ada0s1 и /dev/ada0s2e,
> > но нет /dev/ada0s1c; на предыдущей к этим двум были и /dev/ada0s1c,
> > и /dev/ada0s1ce (!!) и аналогично для остальных букв под ним.
>
> В десятке не бывает ada0s1c, afaik. Ты уверен, что грузил десяточное ядро в
> тот момент?
10.2, абсолютно точно. У меня там нет ядер другого major, вообще, а
10.2 осталось только потому, что не вычистил (судя по описанной рядом
истории с rdrand - правильно сделал, иначе бы просто не загрузился).
> > К сожалению, если не просить verbose boot, dmesg этого ничего не
> > пишет, так что все сегодняшние чудеса в логах не отразились. Знал бы
> > прикуп - сохранил бы kern.geom.confxml для истории.
>
> Пробуй воспроизвести или забей.
Плохая идея. Потому что такая неустойчивость уже приводила к тому, что
приходилось в аварийном порядке требовать iKVM для вроде бы простой и
банальной операции. Хочется таки успокоить его в одном состоянии, ну и
разобраться, что же вызывает все эти эффекты.
-netch-
