Коли ви використовуєте pivot_root над switch_root?


19

Я хочу краще зрозуміти процес init Linux для того, щоб перезавантажити систему через ceph, а не nfs.

У процесі я натрапив на дві форми перемикання root. Один називається switch_root, а другий називається pivot_root. Ці сценарії виконуються з файлової системи пам'яті (initramfs), отриманої через tftp, використовуючи процес завантаження pxe.

Коли ви використовуєте одне над іншим? Я бачив і те, і інше, що використовується в якомусь скрипті init, розміщеному в корені.

Відповіді:


16

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

Коротша версія

  1. Поки система завантажується, вона потребує раннього простору користувача. Цього можна досягти, використовуючи або initramfs, або initrd.
  2. initrd завантажується в ramdisk, який є фактичною СИСТЕМОЮ ФАЙЛУ .
  3. initramfs це НЕ файлова система .
  4. Для initrd pivot_root використовується і для initramfs switch_root використовується.

Більш довга версія

Тепер до детального пояснення того, що я виклав вище.

Хоча і initramfs, і initrd служать одній і тій же цілі, є 2 відмінності. Найбільш очевидна відмінність полягає в тому, що initrd завантажується в рамковий диск. Він складається з фактичної файлової системи (як правило, ext2), яка встановлена ​​у рамному диску. З іншого боку, initramfs - це не файлова система. Це просто (стислий) архів cpio (типу newc), який розпаковується в tmpfs. Це має побічний ефект, що робить initramfs трохи оптимізованішим і здатним завантажуватися трохи раніше в процесі завантаження ядра, ніж initrd. Крім того, розмір initramfs в пам'яті менше, оскільки ядро ​​може адаптувати розмір tmpfs до того, що фактично завантажено, а не спиратися на попередньо визначені розміри ramdisk,

Існує також ще одна різниця побічних ефектів: як керувати кореневим пристроєм (і перемикатися на нього). Оскільки initrd - це фактична файлова система, розпакована в операційний пам'ять, кореневим пристроєм фактично повинен бути ramdisk. Для initramfs існує ядро ​​"rootfs", яке стає tmpfs, в яке initramfs розпаковане (якщо ядро ​​завантажує initramfs; якщо ні, то rootfs - це просто файлова система, вказана через параметр завантаження root = kernel), але цей тимчасовий rootfs не повинен бути вказаний як параметр root = boot (і не було б способу зробити це, оскільки до нього не приєднано жодного пристрою). Це означає, що ви все ще можете передавати свій справжній кореневий пристрій до ядра під час використання initramfs. За допомогою initrd ви повинні обробити те, що є справжнім кореневим пристроєм. Також, оскільки "справжній" кореневим пристроєм з initrd є ramdisk, ядро ​​має дійсно переносити кореневі пристрої з одного реального пристрою (ramdisk) на інший (ваш справжній корінь). У випадку з initramfs простір initramfs (tmpfs) не є реальним пристроєм, тому ядро ​​не перемикає реальні пристрої. Таким чином, хоча команда pivot_root використовується з initrd, для initramfs слід використовувати іншу команду. Busybox надає перемикач_root для цього, а klibc пропонує new_root. для initramfs слід використовувати іншу команду. Busybox надає перемикач_root для цього, а klibc пропонує new_root. для initramfs слід використовувати іншу команду. Busybox надає перемикач_root для цього, а klibc пропонує new_root.


2
Я використовував pivot_rootу минулому для initramfs, switch_rootне існував на той час. switch_rootЗдається, зручним методом, pivot_rootякий робить ще чисте очищення, а також переміщення /proc /sysі /devт. д., а не лише сам корінь
Даніель Олдер

2
Ви не можете використовувати pivot_root для initramfs rootfs, ви отримаєте Недійсний аргумент. Ви можете перемикати лише реальні файлові системи.
TiCPU

@TiCPU Тоді як Linux вийде з раннього користувальницького простору?
Мелаб

Надане рішення, здається, неправильне. Сам Лінус каже, що pivot_root () або chroot () просто змінять поточні посилання на процеси /. Отже, з мого розуміння, це може бути будь-який шлях і не має нічого спільного з фактичними "дисками".
erikbwork

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.