On 25.10.2016 09:56, Valentin Nechayev wrote: > Если механизм "открыли по diskid - пропало по иерархии подключения" > работает, как ты описал, то он сработал не на этом уровне, а на уровне > всего диска. При этом появились /dev/ada1p${X} и пропали > /dev/diskid/DISK-${ID}p${X} _все одновременно_.
Естественно, ведь если нет целого диска, то не может быть и разделов на нём. Исходно пропал весь /dev/diskid/DISK-${ID}, а разделы на нём уже как следствие. > Ещё раз: состав опций GEOM не менялся между вариантами. Кроме того, он > в точности совпадает с GENERIC. "Кто-то" в состоянии проконтролировать > эти детали и начинает уже открытым текстом удивляться, почему второй > "кто-то" этому не верит. Не верю никому, и даже себе :-) Потому что чудес не бывает. Пока не будет исчерпывающего описания структуры дисков, конфигов и действий или воспроизведения - считаю за pilot error как наиболее вероятное. >>> А, значит, по сравнению с тем, что ты говоришь - кто-то таки мешает >>> созданию diskids, причём для всего диска. >> >> Я же показал, что diskid не видно просто потому, что соответствующие >> объекты заняты геомами PART_* > > Гипотеза не проходит. Картина с конкретным присутствием только одного из > вариантов видна в полном составе уже на момент загрузки в single user > до подключения любых объектов со второго диска. Корень находится на > ada0, своп не активирован, ZFS не активирован, клиентов (в нормальном > смысле) ни на что на ada1 ещё нет. По-твоему, при этом должны были > быть видны оба набора объектов в /dev/, так? Да. Если одного из них не было - значит, кто-то таки держал открытым диск. Пробуй воспроизвести или забей. >> Оба одновременно при открытых провайдерах на фре не бывает afaik. > > При открытых, гм, "провайдерах". Вот я и говорю - похоже, что или > "провайдер" GPT хватает диск раньше, создавая /dev/ada1p${X}, или > label делает это раньше, создавая свои id. > Ты же описываешь в своём примере параллельность работы label к > остальным. Они "хватают" параллельно, да. А исчезает одно из них потом, при открытии. > А вот что интересно, кстати. Если посмотреть сейчас чуть по другому > пути: > > $ 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 не убирает > его из видимости? Именно потому, что он занят ZFS по gptid, он и не исчезает. > Я отмонтировал 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, будут > ли они оба присутствовать? И будут ли присутствовать, в идеале, все > три, пока ни один не подключен? Ты не путай, diskid это глобальный уровень диска, а не какой-то там раздел внутри. Вообще для ясности очень рекомендую sysctl -n kern.geom.confdot > geom.dv и затем на любой машине, где есть установлен graphviz, сделать dot -Tsvg geom.dv > geom.svg и открыть geom.svg в браузере и поизучать его. И показать. Ты так и не описал подробно свой конфиг и я почти не понимаю того, о чём ты пытаешься рассказать :-) >> Пробуй воспроизвести или забей. > > Плохая идея. Потому что такая неустойчивость уже приводила к тому, что > приходилось в аварийном порядке требовать iKVM для вроде бы простой и > банальной операции. Хочется таки успокоить его в одном состоянии, ну и > разобраться, что же вызывает все эти эффекты. Так воспроизводи.