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 для истории. Пробуй воспроизвести или забей.
