Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
On 25.10.2016 11:53, Valentin Nechayev wrote: >> Смонтировать часть разделов диска через diskid? а другую часть разделов >> этого же диска через /dev/adaN* возможно не получится. > > Это „возможно“ очень „радует“. Не "возможно", а однозначно не получится - при открытии одного пропадает другой.
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
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 для вроде бы простой и
> банальной операции. Хочется таки успокоить его в одном состоянии, ну и
> разобраться, что же вызывает все эти эффекты.
Так воспроизводи.
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
hi,
Tue, Oct 25, 2016 at 00:14:47, citrin wrote about "Re: [freebsd] /dev/ada*p*
или /dev/diskid/DISK-${id}p*?":
> On 10/23/16 12:34, Valentin Nechayev wrote:
> > а от чего зависит, при буте будут видны имена первого или второго типа?
> > При переходе на 10.3 вдруг активировались diskid'ы, пришлось менять fstab.
> > Сегодня на новом ядре вдруг вернулись ada* варианты, опять менять fstab.
> >
> > И, главное, оба одновременно - почему-то не сделали...
>
> Как уже было сказано - до монтированая (или включения диска в gmirror и
> т. п.) должны быть видны оба варианта одновременно.
Как уже было рассказано, именно этого и не было. Был виден только один
вариант.
Вместе с безумными артефактами типа /dev/ada0s1ce меня это приводит к
однозначному выводу - что что-то там во всём этом механизме нарушено
(и не мной, я так не умею извращать;))
> Если в fstab все ФС были прописаны как /dev/adaN* то должно работать в
> таком виде и в 10.3 и в других версиях.
>
> Смонтировать часть разделов диска через diskid? а другую часть разделов
> этого же диска через /dev/adaN* возможно не получится.
Это „возможно“ очень „радует“.
> Чтобы было понятно что происходит рекомендую добавить в loader.conf
> kern.geom.label.debug=1
Ну на следующие подёрги так и сделаю.
-netch-
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
On 10/23/16 12:34, Valentin Nechayev wrote: а от чего зависит, при буте будут видны имена первого или второго типа? При переходе на 10.3 вдруг активировались diskid'ы, пришлось менять fstab. Сегодня на новом ядре вдруг вернулись ada* варианты, опять менять fstab. И, главное, оба одновременно - почему-то не сделали... Как уже было сказано - до монтированая (или включения диска в gmirror и т. п.) должны быть видны оба варианта одновременно. Если в fstab все ФС были прописаны как /dev/adaN* то должно работать в таком виде и в 10.3 и в других версиях. Смонтировать часть разделов диска через diskid? а другую часть разделов этого же диска через /dev/adaN* возможно не получится. Чтобы было понятно что происходит рекомендую добавить в loader.conf kern.geom.label.debug=1
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
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-
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
On 24.10.2016 03:19, Valentin Nechayev wrote: >>> У меня нет над ними ничего вообще. Это просто два диска. >> А причем тогда 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 >> Если "просто два диска" без разметки, понимаемой >> GEOM_PART_*, то никакой GEOM и не занимает диски и не мешает созданию diskid, >> тогда это штатное поведение системы. Если после этого нечто вроде ZFS >> откроет diskid, то ada* пропадут. Так и задумано. > > В данном случае я вообще привёл id _свопа_. Никакой ZFS тут не > участвует. Неважно, своп тоже открывается ядром при выполнении swapon, та же хрень. > Но такое же происходит и с двумя соседними UFS разделами, > причём со всеми одновременно - у ada1 или появляются p1, p2..., > или у serialʼа диска появляются подзаписи p1, p2... в diskid. Появляется всё, просто diskid пропадает в момент монтирования. Или пропадает ada* при открытии diskid. Или ada* не появляется, потому что кто-то собрал ядро вообще без GEOM_PART_* > А, значит, по сравнению с тем, что ты говоришь - кто-то таки мешает > созданию diskids, причём для всего диска. Я же показал, что diskid не видно просто потому, что соответствующие объекты заняты геомами PART_* >> Упомянутый loader tunnable запрещает создание diskid полностью. >> Скорее всего, тебе надо его выставить в ноль и расслабиться. > > Я, наоборот, предпочёл бы видеть, как будто он всегда в 1, а лучше в 2 > (чтобы присутствовали оба варианта). :) Оба одновременно при открытых провайдерах на фре не бывает afaik. >>> Ага. То есть может быть race? >> >> Не думаю, ни разу не видел race в GEOM, там всё детерминировано, >> хотя и не очевидным образом. У разных GEOM разные свойства - кто-то >> захватывает диск эксклюзивно, кто-то нет; кто-то получает его на >> "обнюхивание" >> (taste) раньше, кто-то позже. > > Тем не менее, что-то там работает неустойчиво. > На текущей загрузке есть, например, /dev/ada0s1 и /dev/ada0s2e, > но нет /dev/ada0s1c; на предыдущей к этим двум были и /dev/ada0s1c, > и /dev/ada0s1ce (!!) и аналогично для остальных букв под ним. В десятке не бывает ada0s1c, afaik. Ты уверен, что грузил десяточное ядро в тот момент? > К сожалению, если не просить verbose boot, dmesg этого ничего не > пишет, так что все сегодняшние чудеса в логах не отразились. Знал бы > прикуп - сохранил бы kern.geom.confxml для истории. Пробуй воспроизвести или забей.
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
24.10.2016 0:07, Valentin Nechayev пишет: 1. На GENERIC тоже видны только одни из. Только ada это нормально. Только diskid сразу после загрузки? - прошу показать dmesg.boot 2. Что такое "норма" по-твоему? Выше. Прошу показать вывод ls -l /dev/diskid/ и ls -ld /dev/ad* с машины, где, по-твоему, "норма". В норме у меня нет в diskid ничего просто потому, что в норме другие провайдеры эксклюзивно занимают ada* и не дают glabel'ному diskid шанса занять их. Но могу легко это устроить: берем рабочий gmirror, состоящий из SATA-дисков ada1 и ada2 и удаляем из него ada2 (gmirror remove gm0 ada2), после чего получаем: # ls -l /dev/ada[12]* crw-r- 1 root operator 0x7c 13 окт 21:41 /dev/ada1 crw-r- 1 root operator 0x7e 13 окт 21:41 /dev/ada2 crw-r- 1 root operator 0xd6 24 окт 01:27 /dev/ada2s1 crw-r- 1 root operator 0xdd 24 окт 01:27 /dev/ada2s1a crw-r- 1 root operator 0xdf 24 окт 01:27 /dev/ada2s1b crw-r- 1 root operator 0xe1 24 окт 01:27 /dev/ada2s1e crw-r- 1 root operator 0xe3 24 окт 01:27 /dev/ada2s1f crw-r- 1 root operator 0xe5 24 окт 01:27 /dev/ada2s1g crw-r- 1 root operator 0xe7 24 окт 01:27 /dev/ada2s1h crw-r- 1 root operator 0xd8 24 окт 01:27 /dev/ada2s2 crw-r- 1 root operator 0xe9 24 окт 01:27 /dev/ada2s2a # ls -l /dev/diskid total 0 crw-r- 1 root operator 0xd5 24 окт 01:27 DISK-WD-WCAWFA251128 crw-r- 1 root operator 0xdb 24 окт 01:27 DISK-WD-WCAWFA251128s1 crw-r- 1 root operator 0xeb 24 окт 01:27 DISK-WD-WCAWFA251128s1a crw-r- 1 root operator 0xec 24 окт 01:27 DISK-WD-WCAWFA251128s1b crw-r- 1 root operator 0xed 24 окт 01:27 DISK-WD-WCAWFA251128s1e crw-r- 1 root operator 0xee 24 окт 01:27 DISK-WD-WCAWFA251128s1f crw-r- 1 root operator 0xef 24 окт 01:27 DISK-WD-WCAWFA251128s1g crw-r- 1 root operator 0xf0 24 окт 01:27 DISK-WD-WCAWFA251128s1h crw-r- 1 root operator 0xdc 24 окт 01:27 DISK-WD-WCAWFA251128s2 crw-r- 1 root operator 0xf1 24 окт 01:27 DISK-WD-WCAWFA251128s2a # smartctl -a /dev/ada2 | grep ^Serial Serial Number:WD-WCAWFA251128 # gmirror insert gm0 ada2 # ls -l /dev/diskid ls: /dev/diskid: Нет такого файла или каталога glabel получает шанс создать diskid в этом случае потому, что он же не может создать другого провайдера типа ufs label на тех же объектах - UFS-метки совпадают с метками разделов смонтированного зеркала. 3. Мой конфиг отличается от GENERIC очень малым - в основном, урезано огромное количество левых устройств. Самая большая диверсия там - IPFIREWALL_DEFAULT_TO_ACCEPT. Секция GEOMʼов не трогалась _совсем_. Сборка тоже стандартными способами. Поэтому твои наезды сомнительны. Это не наезды, это констатация факта. Чудес не бывает, а у тебя проявилось кривое поведение, которое не проявляется в норме. Либо ты что-то не договариваешь про свою конфигурацию - кроме ядра ещё имеют значения навороты разбиения и иерархия GEOM-ов над ними; либо прокосячил. Любой может допустить pilot error, в этом нет ничего позорного.
[freebsd] Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
23 октября 2016 г., 19:54 пользователь Valentin Nechayev <
ne...@netch.kiev.ua> написал:
>
> Sun, Oct 23, 2016 at 23:42:51, eugen wrote about "Re: [freebsd]
> /dev/ada*p* или /dev/diskid/DISK-${id}p*?":
>
> > > а от чего зависит, при буте будут видны имена первого или второго типа?
> >
> > Возможно, от kern.geom.label.disk_ident.enable
>
> Сейчас равен 1. /dev/diskid отсутствует.
У меня в скрипте инсталла давно забито:
echo kern.geom.label.gptid.enable=0 >> /mnt/boot/loader.conf
echo kern.geom.label.disk_ident.enable=0>> /mnt/boot/loader.conf
Чтоб не было чудес со сменой GPT меток после обновления.
--
Vladislav V. Prodan
System & Network Administrator
support.od.ua
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
Sun, Oct 23, 2016 at 23:59:29, eugen wrote about "Re: [freebsd] /dev/ada*p*
или /dev/diskid/DISK-${id}p*?":
> >> Что значит "активировались" и зачем менять fstab?
> >
> > В системе два диска, первый под DOS разбиением, второй под GPT.
> > На первом были /dev/ada0s{1,2,3...}
> > На втором до перехода были /dev/ada1p{1,2,3...}
> > а после вдруг появились /dev/diskid/DISK-p{1,2,3...}, а
> > /dev/ada1p{1,2,3...} пропали.
>
> Это ты что-то накосячил с конфигом ядра. В норме такого не бывает.
1. На GENERIC тоже видны только одни из.
2. Что такое "норма" по-твоему? Прошу показать вывод ls -l
/dev/diskid/ и ls -ld /dev/ad* с машины, где, по-твоему, "норма".
3. Мой конфиг отличается от GENERIC очень малым - в основном, урезано
огромное количество левых устройств. Самая большая диверсия там -
IPFIREWALL_DEFAULT_TO_ACCEPT. Секция GEOMʼов не трогалась _совсем_.
Сборка тоже стандартными способами. Поэтому твои наезды сомнительны.
-netch-
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
23.10.2016 23:54, Valentin Nechayev пишет:
Что значит "активировались" и зачем менять fstab?
В системе два диска, первый под DOS разбиением, второй под GPT.
На первом были /dev/ada0s{1,2,3...}
На втором до перехода были /dev/ada1p{1,2,3...}
а после вдруг появились /dev/diskid/DISK-p{1,2,3...}, а
/dev/ada1p{1,2,3...} пропали.
Это ты что-то накосячил с конфигом ядра. В норме такого не бывает.
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
hi,
Sun, Oct 23, 2016 at 23:42:51, eugen wrote about "Re: [freebsd] /dev/ada*p*
или /dev/diskid/DISK-${id}p*?":
> > а от чего зависит, при буте будут видны имена первого или второго типа?
>
> Возможно, от kern.geom.label.disk_ident.enable
Сейчас равен 1. /dev/diskid отсутствует.
> Но не вместо ada*, а в дополнение к.
В том и дело, что получается вместо. Есть в /dev или одни, или другие.
> > При переходе на 10.3 вдруг активировались diskid'ы, пришлось менять fstab.
>
> При переходе с которой версии?
С 10.2.
> Что значит "активировались" и зачем менять fstab?
В системе два диска, первый под DOS разбиением, второй под GPT.
На первом были /dev/ada0s{1,2,3...}
На втором до перехода были /dev/ada1p{1,2,3...}
а после вдруг появились /dev/diskid/DISK-p{1,2,3...}, а
/dev/ada1p{1,2,3...} пропали.
> Сохранился ли лог загрузки (в kernel.log или console.log, all.log),
> в котором нет ada*?
Увы, всё проэкспайрилось.
-netch-
Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
23.10.2016 23:34, Valentin Nechayev пишет: hi, а от чего зависит, при буте будут видны имена первого или второго типа? Возможно, от kern.geom.label.disk_ident.enable Но не вместо ada*, а в дополнение к. При переходе на 10.3 вдруг активировались diskid'ы, пришлось менять fstab. При переходе с которой версии? Что значит "активировались" и зачем менять fstab? Сохранился ли лог загрузки (в kernel.log или console.log, all.log), в котором нет ada*?
[freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?
hi, а от чего зависит, при буте будут видны имена первого или второго типа? При переходе на 10.3 вдруг активировались diskid'ы, пришлось менять fstab. Сегодня на новом ядре вдруг вернулись ada* варианты, опять менять fstab. И, главное, оба одновременно - почему-то не сделали... Такое впечатление, что на момент компиляции вписывается фаза Луны. Хорошо, что не при буте, но всё равно непонятно...
