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

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

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

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

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

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

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

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

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

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

There is no generic standard for labels, it's all hand-knitted, see for example this implementation of superblocks formats in util-linux. If you invent a new filesystem tomorrow, even if it has a label, it won't show up until support is added.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  ---

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