Почему номер диска / раздела все еще используется?

Много раз, особенно когда возиться с загрузчиками, я буду видеть числовые номера дисков и разделов. Например, в моем, /boot/grub/grub.cfgя вижу set root='hd0,gpt2', мои загрузочные записи UEFI часто ссылаются на номера дисков / разделов, и кажется, что они возникают почти в любом контексте, когда речь идет о загрузчиках.

Теперь, когда у нас есть UUID и PARTUUID, адресация разделов таким образом кажется невероятно нестабильной (на самом деле, диски не всегда гарантированно монтируются в одном и том же порядке, пользователь может переместить порядок подключения дисков в их mobo и т. Д.)

Поэтому мои вопросы имеют два аспекта:

1. Является ли эта схема адресации нестабильной, как я обрисовал выше? Я что-то упускаю в стандарте, что означает, что эта схема намного надежнее, чем я ожидал, или эта схема адресации действительно сделает вашу систему не загружаемой (пока вы не исправите загрузочные записи, по крайней мере) в результате того, что ваши диски просто распознаются в другой порядок или вставляете их в разные слоты на материнской плате?

2. Если ответ на поставленный выше вопрос - «да», то почему эта схема адресации продолжает использоваться? Разве использование UUID или PARTUUID для всего не будет намного более стабильным и последовательным?

Схема простой нумерации фактически не используется в последних системах (с «недавним» Ubuntu 9 и более поздними версиями, другие дистрибутивы также могли адаптироваться в ту эпоху).
Вы правы в том, что корневой раздел установлен по простой схеме нумерации. Но это только настройка по умолчанию или резервная настройка, которая обычно переопределяется следующей командой, такой как:

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

Это выбирает корневой раздел на основе UUID файловой системы.

На практике схема простой нумерации обычно стабильна (до тех пор, пока нет аппаратных изменений). Единственный случай, когда я наблюдал непредсказуемую нумерацию, - это система со многими USB-накопителями, которые были перечислены по принципу «первым пришел - первым обслужен», а затем эмулированы как диски IDE. Ни один из этих процессов не является хаотическим по своей природе, поэтому я предполагаю проблему в реализации конкретной системы BIOS.

Примечание: «корневой раздел» в данном контексте означает раздел для загрузки, он может отличаться от раздела, содержащего «root aka. / File system».

Строго говоря, UUID вообще не обращается .

Адресация очень и очень проста: читать диск X сектора Y - или еще. Считать адрес памяти Z - или еще. Адресация проста, быстра, оставляет мало места для интерпретации, и это везде.

UUID не обращается. Вместо этого это поиск, поиск, иногда ожидание появления устройств, а также понимание файловых систем (★). И в зависимости от количества устройств, это может занять очень много времени. И как только нашли, вернемся к обычной адресации это.

В GRUB это называется search(★★) и доступно только тогда, когда GRUB уже имеет крылья (поиск - это модуль, как и любая файловая система, которую он поддерживает, и, следовательно, доступный только после загрузки ядра). В Linux, он называется (например) findfs, findfs будет искать блочные устройства в системе в поисках файловой системы или раздела .

Он проходит через все блочные устройства, выводит их из режима ожидания, читает данные, и результат может даже быть случайным, если UUID не является уникальным, как это должно быть (после dd аварии или тому подобного), или вы не получите результата, если UUID изменился - UUID также подвержены ошибкам конфигурации.

В целом, UUID являются отличными, и, конечно, вы должны использовать их везде, если они доступны, особенно когда традиционная адресация обречена на неудачу, потому что порядок дисков в Linux является случайным; но поймите, что сложность выше и выше того, что подразумевается под простой адресацией. И особенно на самых ранних стадиях загрузчиков, это просто может быть еще не вариант. Сначала идет адресация, потом растут крылья.

Для загрузчика может просто не потребоваться приложить усилия (не каждый загрузчик поддерживает широкий спектр файловых систем, таких как GRUB). Если hd0гарантировано, что это «диск, с которого мы загрузились» из-за обстоятельств (в BIOS), и поэтому, если вы можете исключить проблемы со случайным порядком дисков, возможно, вам не понадобится просматривать потенциально огромный список других разделов в поиск UUID.

Если вы достаточно уверены в своей конфигурации, чтобы сказать, что hd0,gpt2это именно то, что вам нужно, и это должно быть, и не может быть иначе, тогда нет ничего плохого в использовании этого. Иногда простая и простая адресация работает просто отлично.

(★) Я ранее объяснил это для ЭТИКЕТКИ здесь ...

Универсального стандарта для меток не существует, все связано вручную, см., Например, эту реализацию форматов суперблоков в util-linux . Если завтра вы придумаете новую файловую систему, даже если у нее есть метка, она не появится, пока не будет добавлена ​​поддержка.

... и то же самое для UUID.

(★★) На самом деле, у GRUB searchесть --hintопция, и ... теперь я не проверял исходный код, и он даже не задокументирован в их руководстве, но такая опция имеет смысл дать вам лучшее из обоих миров: намек должен сказать , searchчтобы проверить , что раздел первый , и если UUID матчи , как и ожидалось, он определил устройство с минимальным усилием , и если он не совпадает, он все равно вернется к полному выдувного поиска , чтобы все работало как - то ,

В дополнение к этому ранее найденные UUID имеют тенденцию кешироваться, поэтому не нужно проходить через все устройства снова и снова и снова - и это тоже прекрасно работает, при условии, что UUID, который вы ищете, действительно существует где-то, чтобы сделать это в кеш в первую очередь.

Также не забывайте этикетки. Они не так уникальны, как UUID, но гораздо более информативны и делают ваш fstab понятным для человека. Если это ваш рабочий стол или небольшая компания - иными словами, вы управляете несколькими или несколькими десятками дисков, вы можете предпочесть метки UUID.

Если подумать об отличном ответе @ frostschutz на ваш вопрос, то одним из сценариев, когда вы, вероятно, предпочтете «классическую» адресацию ссылок на устройства, является настройка виртуальной машины, особенно в облаках VM-for-hire (сокращенно, смущенно, «IaaS»). Предположим, вы хотите настроить изображение Ubunzima 04.18 . Вы создаете (одноразовую) виртуальную машину с 2 дисками: один будет (одноразовым) системным диском, а второй - монтируемым и настраиваемым. Предположительно, вы также монтируете его загрузочный раздел UEFI, если хотите записать новый диск на новый диск. Предполагая, что вы выбрали точки монтирования для целевых разделов /mnt, ваша желаемая таблица монтирования выглядит следующим образом

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

Таким образом, вы создаете 2 идентичных диска из существующего, предоставленного провайдером, готового к работе в облаке образа, подключаете их к новой виртуальной машине и загружаете ее. Естественно,

• Все современные дистрибутивы ОС, наша воображаемая Ubunzima 04.18 не является исключением, используют UUID-названные монтирования.
• Все жесткие диски, развернутые с одного образа, имеют одинаковый UUID. UUID уникальны, так что может пойти не так?

Вы уже видите, куда это все идет.

При первом запуске этого frankencontraption он был выбран sda9как загрузочный раздел EFI, но Linux решил перемонтировать его sdb1в качестве корневого FS:

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

И так как мой сценарий развертывания был совершенно не подготовлен к этому, в итоге у меня получилось не загружаемое грязное изображение, без единого инструмента, жаловавшегося в журнале во время frankenbuild!

Конечно, я напечатал таблицу монтирования в журналах. И, конечно, путаницу очень трудно обнаружить, так как mount (8) печатает монтирования в порядке, находящемся посередине между случайным и тем, в котором были установлены устройства, так что неудивительно, что я не заметил это сразу. И представьте, тот же сценарий (но с дисками из разных образов) ранее работал так же гладко, как 15-летний Гленфиддич. Угадай, сколько часов я потянул за волосы, пытаясь выяснить проблему?

Не существует жестких и быстрых правил, подходящих для любой ситуации: от настольного ПК до Linux, встроенного в маршрутизатор, от телефона Android до облачного центра обработки данных. Ответ SO должен быть объективным, а мой опыт или предпочтения, конечно, нет. Поэтому я бы предпочел показать примеры логических рассуждений при выборе различных методов идентификации разделов:

• Оставьте это в покое, если у вас нет причин не делать этого. UUID - это значение по умолчанию для большинства современных дистрибутивов. Если дело доходит до добавления второго диска, попробуйте и решите. Скорее всего, вам даже не нужно будет об этом знать. Если ваша система все еще загружается, и вы можете увидеть и разбить новое устройство, отформатируйте и добавьте его в fstab (по UUID, по LABEL или по /devссылке, применяются те же соображения). Только когда ваша система отказывается загружаться после подключения дополнительного диска, у вас возникает проблема (и, возможно, изменение порядка загрузки в UEFI BIOS - самый быстрый выход).

  Прагматично, маркировка того, какой разъем SATA идет к тому или иному диску в вашем собственном рабочем столе, может быть самым быстрым и простым решением, а изменение способа загрузки системы и восстановление после весьма вероятного сбоя загрузки, возможно, является худшим временным гоблером. Но если вам удастся справиться с этим для 50 программистов, которые считают, что добавление дополнительного диска не является проблемой, которая вас беспокоит, по крайней мере, не проверяйте пределы своей удачи и убедитесь, что все их начальные загрузочные диски видятся grub как hd0и система как sda.

• Этикетки для управления вашими собственными дисками и разделами на вашем рабочем столе или трех, или в небольшой среде (гостиная дома, заполненного инженерами-программистами, которые забавно называют это место «офисом запуска»). Если вы извлекаете физический диск из чьей-либо машины, вы знаете, откуда он пришел, если вы используете метки последовательно.

  Если lsblk (8) говорит LABEL=bubba-boot, вы знаете, что он был извлечен из машины, называемой bubba ; кроме того, bubba-boot катится по моему языку намного легче, чем 6864c4ea-f9b9-46db-b875-4d7fc2981007 , который, на мой испорченный вкус, является совершенно челюстным молотом. Гарантия того, что ярлыки являются уникальными, теперь ложится на вас, но вы получаете взамен значимость ярлыка.

• /devприсвоение имен на основе ссылок, когда командуете батальоном относительно недолговечных виртуальных машин с низкими эксплуатационными расходами, которые являются порождением одного и того же образа, и вы не ставите свою еженедельную заработную плату на то, что все их UUID соответствуют обещанию UU. Любой здравомыслящий сервис VM, будь то Vyper-H на вашем физическом сервере, Kugel Cloud или что-то еще, никогда не будет вызывать ваш загрузочный диск sde, а второй и единственный другой sdc². В физической машине, с другой стороны, вы можете легко получить ту же схему, творчески подключив кабели SATA.

  Сейчас я отступаю, но в этом сценарии я иду тем же путем с так называемым «последовательным» наименованием интерфейса Ethernet: отключите его в виртуальных машинах. Не поймите меня неправильно, названия действительно последовательны до тех пор, пока сетевая карта, которую вы вставите в PCI-слот 4, не будет внезапно переходить в слот 5 по своей прихоти, пока вы не смотрите (или, может быть, даже пока вы есть; сетевые карты) не стыдно вообще). К сожалению, в среде «батальона ВМ» они фактически так и делают. В этом случае, нелогично, eth0является более последовательным, чемenp0s4f6, Провайдер виртуальных машин не обещал всегда размещать свой виртуальный NIC номер 1 в слоте 4 на шине PCI 0 (и ни один из 3 упомянутых объектов не является физически реальным), и это всегда будет функция 6. Но вы можете довольно во многом полагаются на первый интерфейс, идущий перед вторым, учитывая, что они обычно имеют один и тот же модуль драйвера, обычно из семейства virtio (и если первый NIC не всегдаeth0 , то применяется то же примечание²).

  ---

¹ образно, конечно. Я слишком долго занимался этим делом, чтобы его оставили.
² Если бы они это сделали, я бы серьезно подумал о том, чтобы убежать от крика, когда они меняют поставщика или программное обеспечение гипервизора ВМ.

Обе схемы могут быть смешаны и сопоставлены с большинством дистрибутивов Linux.

Последствия могут быть желательными или нежелательными в зависимости от варианта использования - например, кто-то может предпочесть более старую схему (и даже отключить постоянные хаки в стиле udev), если горячая замена (виртуального или реального оборудования) дисков без необходимости изменения файлов конфигурации хотел.

Ответ на ваш второй вопрос («почему эта схема адресации продолжает использоваться?»), По-моему, инерционен. Да, на разделенных GPT-дисках можно полностью использовать только UUID. Вы можете использовать UUID вместо /dev/xxxимен в /etc/fstab. И теперь, когда у нас есть Спецификация Обнаруживаемых Разделов , во многих случаях вам даже не нужно больше указывать UUID, просто разделите ваш диск по типу раздела, и разделы будут выбраны автоматически. На моей машине тоroot= запись вообще отсутствует в командной строке ядра.

И если говорить о загрузчиках: GRUB в основном лишний на современных компьютерах UEFI, в том смысле, что он очень мало связан с начальной загрузкой машины. В настоящее время GRUB просто функционирует как программа выбора ядра, для решения которой доступны более простые и лучшие альтернативы, такие как systemd-boot.