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 для вроде бы простой и
> банальной операции. Хочется таки успокоить его в одном состоянии, ну и
> разобраться, что же вызывает все эти эффекты.
Так воспроизводи.
