Алексей Федорчук
На предыдущей странице была рассмотрена номенклатура накопителей, построенная по модели так называемых «имён верхнего уровня». Именно эта модель поддерживается непосредственно ядром DragonFly. И именно с такими именами имеет дело применитель при разметке диска во время установки системы.
Однако при монтировании разделов в файловую иерархию в DragonFly применяется совсем другая модель именования устройств — идентификация по их сериальным номерам. В отличие от номенклатуры «верхнего уровня», она не зависит ни от интерфейса накопителей, ни от порядка их физического подключения: сериальные номера задаются производителем и жёстко прошиты в «железе». И потому эта модель является абсолютно однозначной для именования устройств.
Файлы устройств, именованные по модели сериальных номеров, можно видеть в подкаталоге /dev/serno. На моей машине для диска, на котором установлена DragonFly с файловой системой Hammer, содержание его следующее:
$ ls -1 /dev/serno 5VM0BVYR 5VM0BVYR.s1 5VM0BVYR.s1a 5VM0BVYR.s1b 5VM0BVYR.s1d
Разметка виртуального диска, на который установлена DragonFly с файловой системой UFS, выглядит следующим образом:
$ ls -1 /dev/serno VBcca6f7a6-6d30ce41 VBcca6f7a6-6d30ce41s1 VBcca6f7a6-6d30ce41s1a VBcca6f7a6-6d30ce41s1b VBcca6f7a6-6d30ce41s1d VBcca6f7a6-6d30ce41s1e VBcca6f7a6-6d30ce41s1f VBcca6f7a6-6d30ce41s1g
Легко видеть (см. таблицу), что имена по модели сериальных номеров в обоих случаях однозначно соответствуют «именам верхнего уровня», приведённым на предыдущей странице. Что и не удивительно: это ни что иное, как жёсткие ссылки — то есть разные имена для одних и тех же данных. В чём легко убедиться, сравнив идентификаторы файлов этих устройств командой ls -i:
«Сериальные» имена используются в DragonFly при определении условий автоматического монтирования файловых систем, описываемых в файле /etc/fstab. Для файловой системы Hammer это необходимость, поскольку она является также менеджером логических томов (подробнее разговор на эту тему — впереди). Ну а при использовании UFS тот же способ описания принят был, видимо, «за компанию».
Читатель, знакомый с моделями именования устройств в Linux’е, наверняка уже заметил сходство её модели by-id (она по умолчанию используется, например, в openSUSE) с «сериальной» моделью DragonFly, отражённое в приводимой таблице.
Соответствие «сериальной» модели именования устройств в DragonFly и модели by-id в Linux
| Диск |
DragonFly |
Linux |
||
| Модель имён | «верхнего уровня» | «сериальная» | «верхнего уровня» | by-id |
| SD Extreme SSD 120 | /dev/da0 | 120823400863 | /dev/sda | ata-SanDisk_SDSSDX120GG25_120823400863 |
| /dev/da0s1 | 120823400863.s1 | /dev/sda1 | ata-SanDisk_SDSSDX120GG25_120823400863-part1 | |
| /dev/da0s2 | 120823400863.s2 | /dev/sda2 | ata-SanDisk_SDSSDX120GG25_120823400863-part2 | |
| /dev/da0s3 | 120823400863.s3 | /dev/sda3 | ata-SanDisk_SDSSDX120GG25_120823400863-part3 | |
| SD Extreme SSD 120 | /dev/da1 | 120823402786 | /dev/sdb | ata-SanDisk_SDSSDX120GG25_120823402786 |
| /dev/da1s1 | 120823402786.s1 | /dev/sdb1 | ata-SanDisk_SDSSDX120GG25_120823402786-part1 | |
| /dev/da1s2 | 120823402786.s2 | /dev/sdb2 | ata-SanDisk_SDSSDX120GG25_120823402786-part2 | |
| /dev/da1s3 | 120823402786.s3 | /dev/sdb3 | ata-SanDisk_SDSSDX120GG25_120823402786-part3 | |
| ST3500410AS | /dev/da2 | 5VM0BVYR | /dev/sdc | ata-ST3500410AS_5VM0BVYR |
| /dev/da2s1 | 5VM0BVYR.s1 | /dev/sdc1 | ata-ST3500410AS_5VM0BVYR-part1 | |
| /dev/da2s1a | 5VM0BVYR.s1a |
— |
— |
|
| /dev/da2s1b | 5VM0BVYR.s1b |
— |
— |
|
| /dev/da2s1d | 5VM0BVYR.s1d |
— |
— |
|
Различие в том, что в Linux’е имена by-id — это символические ссылки на «имена верхнего уровня», а не жёсткие ссылки, как в DragonFly. Кроме того, в Linux’е они несколько более громоздкие — в DragonFly из «фабричного» идентификатора отбрасывается всё, что не нужно для однозначного определения устройства.
Кроме «сериальной» модели, в DragonFly поддерживается и аналог Linux’овых имён by-uuid. Их можно посмотреть так:
ls /dev/part-by-uuid
что на моей реальной машине даёт такую картину:
ce9b346c-9782-11e3-baf4-c96000bd52d2 ce9b3474-9782-11e3-baf4-c96000bd52d2 ce9b3478-9782-11e3-baf4-c96000bd52d2
А в виртуалке выглядит следующим образом:
Имена by-uuid генерируются примерно по тем же правилам, что и в Linux’е — и, как и там, только для «родных» разделов. В отличие от Linux’а, они также являются жёсткими ссылками на имена «верхнего уровня». А вот для чего они применяются — я пока не выяснил.
Предварение | Интермедия: содержание | Продолжение
Оглавление