Чому номер диска / розділу все ще використовується?

Багато разів, особливо коли возиться з завантажувачами, я побачу використовувані цифрові номери та номери розділів. Наприклад, у моєму/boot/grub/grub.cfg я бачу set root='hd0,gpt2', мої UEFI завантажувальні записи часто посилаються номера диска / розділу, і, здається, виникають практично в будь-якому контексті , де завантажувачі стурбовані.

Тепер, коли у нас є UUID і PARTUUID, адресація розділів таким чином виглядає неймовірно нестабільною (afaik, диски не гарантуються, що вони змонтуються завжди в одному порядку; користувач може переміщувати порядок включення диска в їх 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це саме те, що ви хочете, і воно повинно бути, а не може бути інакше, тоді нічого поганого в його використанні немає. Іноді просте і просте адресація працює чудово.

(★) Я раніше пояснював це для міток LABEL тут ...

Не існує загального стандарту для міток, це все вручну в'язане, див., Наприклад, реалізацію форматів суперблоків в util-linux . Якщо завтра винайдете нову файлову систему, навіть якщо вона має мітку, вона не з’явиться, поки не буде додана підтримка.

... і це майже те саме для UUID.

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

На додаток до цього раніше знайдені UUID, як правило, кешуються, тому не потрібно переглядати всі пристрої знову і знову і знову - і це теж чудово працює, за умови, що UUID, який ви шукаєте, насправді існує десь внесіть його в кеш-пам'ять в першу чергу.

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

Розмірковуючи над відмінною відповіддю на @ frostschutz на ваше запитання, одним із сценаріїв, коли ви, швидше за все, віддасте перевагу "класичній" адресації посилань на пристрої, є налаштування VM, особливо в хмарах VM для прокату (скорочено, заплутано "IaaS"). Припустимо, ви хочете налаштувати зображення Ubunzima 04.18 . Ви створюєте (викидаючий) VM з двома дисками: один буде системним приводом (викидний), а другий - монтуванням та налаштуванням. Імовірно, ви також змонтуєте його завантажувальний розділ UEFI, якщо ви хочете обробити нову груб на новому диску. Якщо припустити, що ви вибрали точки монтажу для цільових розділів нижче /mnt, виглядає бажана таблиця кріплення

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

Таким чином, ви робите 2 однакових диска з існуючого, наданого провайдером, готового до хмари зображень, підключаєте їх до нового VM та завантажуєте його. Природно,

• Усі сучасні дистрибутиви ОС, наша уявна 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-телефону, до хмарного центру обробки даних. Відповідь ТА повинна бути об'єктивною, і мої переживання чи уподобання, звичайно, ні. Тому я б швидше показав приклади логічних міркувань під час вибору серед різних методів ідентифікації розділів:

• Залиште це в спокої, якщо у вас немає причин цього не робити. UUID є типовим для більшості сучасних дистрибутивів. Якщо ви хочете додати другий привід, спробуйте потім і вирішіть. Швидше за все, вам ніколи не потрібно буде навіть знати. Якщо ваша система все ще завантажується, і ви можете побачити і розділити новий пристрій, відформатуйте його та додайте його до fstab (за допомогою UUID, LABEL або за /devпосиланням, застосовуються ті ж міркування). Це лише тоді, коли ваша система відмовляється завантажуватися після підключення додаткового диска, тоді у вас виникає проблема (і можливо, зміна порядку завантаження в BIOS UEFI - це найшвидший вихід).

  Прагматично, маркування того, який роз'єм SATA переходить до якого диска на вашому власному робочому столі, може бути найшвидшим і найпростішим рішенням, а зміна способу завантаження системи та виправлення після цілком ймовірної відмови завантаження - це, мабуть, найгірший збиток часу. Але якщо ви керуєте цим для 50 програмістів, які вважають, що додавання додаткового диска не є проблемою, гідною турбувати вас, принаймні не перевіряйте межі вашої удачі і переконайтесь, що їх початкові завантажувальні диски всі бачать grub як hd0і система як sda.

• Мітки для керування власними накопичувачами та перегородками на робочому столі чи трьох, або невелике середовище (вітальня будинку, укомплектована інженерами-програмістами, які весело називають місце своїм "запуском офісу"). Якщо ви витягуєте фізичний привід з чиєїсь машини, ви знаєте, звідки він взявся, якщо ви постійно використовуєте етикетки.

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

• /dev-називання на основі посилань, коли командує батальйоном відносно недовговічних ВМ, що не потребують обслуговування, які є породженим тим самим зображенням, і ви не ставте ставку на свою щотижневу заробітну плату, що всі їхні UUID дотримуються обіцянки США. Будь-яка розумна послуга VM, будь то Vyper-H на власному фізичному сервері чи Kugel Cloud або щось інше, ніколи не називатиме ваш завантажувальний привід sde, а другий та єдиний інший sdc². У фізичній машині, з іншого боку, ви можете легко досягти такого ж розташування, творчо підключивши кабелі SATA.

  Зараз я відволікаюсь, але в цьому сценарії я йду тим же маршрутом з так званим "послідовним" іменованням Ethernet-інтерфейсу: відключіть його у віртуальних машинах. Не зрозумійте мене неправильно, найменування дійсно послідовне, доки NIC, який ви помістили в слот PCI 4, раптом не перескочить на слот 5 за своєю примхою, поки ви не дивитесь (а може, навіть поки ви є; NIC не соромся). На жаль, в середовищі "батальйону ВМС" вони насправді є. В цьому випадку лічильник-інтуїтивно, eth0є більш послідовним , ніжenp0s4f6. Постачальник VM не пообіцяв завжди помістити свій віртуальний номер NIC в слот 4 на шині PCI 0 (і жодна з цих 3 згаданих сутностей не є фізично реальною), і що це завжди буде Функція 6. Але ви можете досить багато покладаються на перший інтерфейс, що йде до другого, враховуючи, що вони зазвичай мають один і той же модуль драйверів, як правило, з сімейства virtio (і якщо перший NIC не завжди eth0, то ж примітка² все ще застосовується).

  ---

¹ Образно, звичайно. Я був би, якщо цей бізнес уже занадто довго не залишився.
² Якби вони це зробили, я б серйозно подумав про те, щоб тікати від крику від зміни постачальника або програмного забезпечення гіпервізора VM.

Обидві схеми можна змішувати і співставляти з більшістю дистрибутивів Linux.

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

Відповідь на ваше друге запитання ("чому ця схема адресації продовжує застосовуватися?"), Я думаю, інерція. Так, цілком можливо використовувати лише UUID на розділених дисках GPT. Ви можете використовувати UUID, а не /dev/xxxімена в /etc/fstab. А тепер, коли у нас є Специфікація розділів, що відкриваються , у багатьох випадках вам навіть більше не потрібно вказувати UUID, просто розділіть свій диск на тип розділу і розділи будуть зібрані автоматично. На моїй машині root=запис взагалі відсутній у командному рядку ядра.

А якщо говорити про завантажувачі: GRUB здебільшого зайвий на сучасних ПК UEFI, в тому сенсі, що це дуже мало стосується завантаження машини. У наш час GRUB просто функціонує як програма вибору ядра, для завдання якої доступні більш прості та кращі альтернативи, такі як завантаження системи.