IT News: Digital Camera, OS, Laptop, Smartphone, Smart TV, Sound...

The Author's Project by Valeri N.Kravchuk
Сайт проверен Dr.Web
Меню сайта
  • Главная страница
  • Информация о сайте
  • Дневник
  • Каталог файлов
  • Обратная связь
  • Каталог сайтов
  • FAQ
  • Доска объявлений
  • Форум
  • Фотоальбом
  • Категории раздела
    Измерительная техника, инструменты [278]
    Drones, boats, cars... [99]
    Накопители данных [186]
    Гаджеты для спорта и здоровья... [166]
    Автомобильные гаджеты... [159]
    Сети, сетевые технологии, оборудование... [211]
    Гаджеты, аксессуары... [604]
    News IT, Это интересно, ликбез... [1048]
    Linux и не только [4195]
    Windows 10... [271]
    Планшеты [738]
    Нетбуки, Ноутбуки, Ультрабуки [618]
    Смартфоны, фаблеты.. [4986]
    GPS-навигаторы, трекеры... [49]
    Видеорегистраторы [195]
    mini computers и не только... [365]
    Своими руками [322]
    CB, LPD, PMR- связь... [110]
    Smart TV, UltraHD, приставки, проекторы... [404]
    Радар-детекторы [22]
    DECT, IP-телефоны [18]
    Мультиварки, блендеры и не только... [122]
    Smart Watch [225]
    Блоки питания, Power Banks, зарядки... [340]
    Sound: наушники, плееры, усилители... [568]
    Безопасность IT [478]
    Электронные книги [75]
    Роботы-пылесосы [26]
    electric cars [28]
    Фотокамеры, объективы, искусство фотографии.. [433]
    Время

    Интересные ссылки

    COMPIZOMANIA

    Наш опрос
    Оцените мой сайт
    Всего ответов: 1243
    Статистика
    Анализ веб сайтов

    Яндекс.Метрика

    Рейтинг@Mail.ru Яндекс цитирования

    Russian America Top. Рейтинг ресурсов Русской Америки.

    eXTReMe Tracker

    Правильный CSS!


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Locations of visitors to this page
    Форма входа
    Главная » 2014 » Март » 2 » Накопители в Linux: модели именования
    17:16
    Накопители в Linux: модели именования

    Накопители в Linux: модели именования

    Необходимость в этой заметке я ощутил во время сочинения интермедии в цикле про DragonFly, конкретно -- про модели именования её устройств. Поскольку в этой операционке, как и в Linux'е, номенклатура дисковых накопителей давно уже не сводится к каноническим именам так называемого "верхнего уровня" (/dev/sd?# в Linux'е, /dev/ad# или /dev/da# -- во FreeBSD и DragonFly), о которых повествуется в "толстых" книжках (тем более что последним из таковых на русском языка скоро стукнет десять лет).

    На истории "номенклатурного вопроса" в Linux'е останавливаться не буду -- она достаточно подробно изложена в книжке по истории мира FOSS, которая (всё ещё) готовится к размещению в Библиотеке Блогосайта. Которое сложилось вследствие внедрения udev и последующей разработки объединённой подсистемы ATA-SCSI, поддерживающей любые накопители -- PATA, SATA, eSATA, SCSI, SAS, USB. И её рамках номенклатура накопителей в Linux полностью унифицировалась. Вне зависимости от типа их интерфейса, внешнего или внутреннего исполнения, файл дискового устройства стал выглядеть как /dev/sd?, где ? -- литера (латинского алфавита) в порядке подключения к дисковому контроллеру:

    • сначала к внутренним SATA-разъёмам,
    • затем к дополнительному PATA-разъёму,
    • и наконец, к внешним разъёмам eSATA и USB.

    Правила нумерации разделов на дисках при использовании разметки в стиле msdos остались без изменения:

    • файлы устройств первичных разделов, включая и тот, которому присвоен идентификатор расширенного, носят имена (например) от /dev/sda1 до /dev/sda4;
    • логические разделы в Extended partition по прежнему именуются от /dev/sda5 и далее.

    А при начавшей распространяться схеме разметки GPT с именами дисковых разделов стало и того проще: они получали просто сквозную нумерацию, без всякого разделения на первичные, расширенные и логическими разделы.

    Некоторые очередные коррективы в номенклатуру накопителей внесло появление интерфейса SATA-III: она оказалась зависимой от его реализации в чипсетах материнских плат или внешних контроллеров. Поскольку в чипсетах Intel 7-й серии из шести каналов SATA только два поддерживают SATA-III, оказалось, что последовательность устройств зависит от режима работы SATA-контроллера. В режиме эмуляции IDE диск на первом канале SATA-III получает имя /dev/sda, диск на первом канале SATA-II -- /dev/sdb, диск на втором канале SATA-III -- /dev/sdc. Диски на остальных каналах SATA-II маркируются в алфавитном порядке.

    При переключении же SATA-контроллера в "родной" режим AHCI маркировка дисков становится сквозной: /dev/sda и /dev/sdb -- диски на каналах SATA-III, /dev/sdc и так далее -- на каналах SATA-II.

    Отмеченные разночтения в именовании накопителей в десктопных конфигурациях с одним-двумя дисками обычно не создают проблем для пользователя, хотя при добавлении новых накопителей или "перетасовке" имеющихся могут возникнуть некоторые осложнения, требующие перенастройки загрузчика и (или) правки файла /etc/fstab. Потенциально проблемным может быть и обновление системы. Однако на практике с этим приходилось сталкиваться не часто. Да и с распространением Intel'овских чипсетов 8-й серии и отмиранием режима эмуляции IDE проблема вообще теряет актуальность.

    Однако нынче в Linux'е применяются не только традиционные файловых системы, но и интегрированные системы размещения данных, такие, как btrfs и ZFS on Linux. Поскольку они также исполняют роль менеджеров мультидисковых устройств (подобных автономным softRAID и LVM), однозначность именования задействованных в них накопителей оказывается критически важной. Видимо, (в том числе и) поэтому наряду с "классической" номенклатурой накопителей (она именуется моделью имён верхнего уровня и поддерживается непосредственно ядром) всё более широко применяются иные модели именования. Хотя однозначность соответствия дисковых устройств их именам не менее важна и для упомянутых выше программного RAID и LVM.

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

    • метке тома (by-label),
    • идентификатору диска (by-id),
    • пути к дисковому устройству (by-path),
    • наконец, по пресловутому универсальному уникальному идентификатору, Universally Unique IDentifier (by-uuid).

    Есть ещё несколько моделей идентификации накопителей, вроде by-partlabel или by-partuuid, но с примерами практического использования их я не сталкивался, и говорить не буду.

    С идентификацией по метке тома, вероятно, многие из читателей моего сочинения знакомы -- этот метод использовался задолго до появления не только udev, но даже devfs. Метка (label -- не путать с disk label, то есть схемой дисковой разметки) -- это просто некоторое условное имя, желательно мнемонически прозрачное. Оно присваивается дисковым разделам -- либо пользователем вручную при разметке, либо генерируется автоматически инсталляторами некоторых дистрибутивов. Список "помеченных" разделов в системе можно просмотреть так:

    # ls -l /dev/disk/by-label
    
    lrwxrwxrwx ... raidboot -> ../../md0
    lrwxrwxrwx ... raidroot -> ../../md1

    Из этого вывода легко понять, что метки (как и все остальные имена устройств, о которых речь пойдёт ниже)-- это символические ссылки на файл "верхнего уровня" (в примере -- на программные RAID).

    Метки тома является атрибутом раздела и не зависят от изменения имён верхнего уровня при реконфигурировании машины. Поэтому во многих случаях их удобно использовать для автоматического монтирования файловых систем, фигурирующих в файле /etc/fstab. Однако по умолчанию, насколько я знаю, ни в одном дистрибутиве Linux они не используются.

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

    UUID'ы представляют собой зубодробительные 128-битные числа, генерируемые для накопителей и их разделов по правилам, описываемым в библиотеке libuuid, и выглядят (в шестнадцатеричной системе счисления) примерно так:

    # ls -l /dev/disk/by-uuid
    итого 0
    lrwxrwxrwx ... 1218e946-7f6b-4e27-beea-07fc6c06bf7a -> ../../sdc2
    lrwxrwxrwx ... 2eec0b23-343f-4e3d-8507-dd042c876a60 -> ../../md0
    lrwxrwxrwx ... 329f123c-17d6-4431-b4f1-583a7f59d8db -> ../../sdd1
    lrwxrwxrwx ... 380c1570-d039-4ac6-ac6a-81321ea465d9 -> ../../sdc4
    lrwxrwxrwx ... 9a76161d-ef7b-4a0d-afc8-c54e68857fee -> ../../sdc5
    lrwxrwxrwx ... e63a68da-eb73-490b-b056-01c4945dca13 -> ../../md1
    lrwxrwxrwx ... e8304d6c-a136-4c97-87d4-cb9a456af791 -> ../../sdc3

    Общее количество уникальных идентификаторов исчисляется величиной 2128, что гарантирует от случайного их повторения, откуда и его название. Однако для человеческого восприятия UUID весьма сложны, и лишены всякой мнемоники. Почему их и нельзя считать самыми удобными средствами именования носителей. Кстати, в ZFS UUID'ы, по каким-то причинам, не используются.

    Если с моделями именования by-label и by-uuid, как я уже говорил, мой потенциальный читатель наверняка так или иначе сталкивался, то рискну предположить, что с идентификацией by-path и by-id дела, скорее всего, не общался. Я, например, долгое время знал о них только по наслышке -- пока не начал плотное знакомство.

    Модель именования by-path использует имена устройств, привязанные к их положению на шине PCI и включающие номер шины и канала на ней, примерно по тому же принципу, что и при использовании devfs (кто помнит, как оно было). Практически это выглядит примерно так:

    # ls -l /dev/disk/by-path
    итого 0
    lrwxrwxrwx ... pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
    lrwxrwxrwx ... pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
    lrwxrwxrwx ... pci-0000:00:1f.2-scsi-0:0:0:0-part2 -> ../../sda2
    lrwxrwxrwx ... pci-0000:00:1f.2-scsi-0:0:0:0-part3 -> ../../sda3
    lrwxrwxrwx ... pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sdb
    lrwxrwxrwx ... pci-0000:00:1f.2-scsi-1:0:0:0-part1 -> ../../sdb1
    lrwxrwxrwx ... pci-0000:00:1f.2-scsi-1:0:0:0-part2 -> ../../sdb2
    lrwxrwxrwx ... pci-0000:00:1f.2-scsi-1:0:0:0-part3 -> ../../sdb3

    Легко догадаться, что дисковые разделы маркируются добавлением к имени устройства суффикса part#.

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

    Модель идентификации by-id представляет имена носителей информации в форме, наиболее доступной для людского понимания. Они образованы из названия интерфейса, имени производителя, номера модели, серийного номера устройства и, при наличии раздела, номера такового:

    # ls -l /dev/disk/by-id 22:07 pts/4
    итого 0
    lrwxrwxrwx 1 ... ata-SanDisk_SDSSDX120GG25_120823400863 -> ../../sda
    lrwxrwxrwx 1 ... ata-SanDisk_SDSSDX120GG25_120823400863-part1 -> ../../sda1
    lrwxrwxrwx 1 ... ata-SanDisk_SDSSDX120GG25_120823400863-part2 -> ../../sda2
    lrwxrwxrwx 1 ... ata-SanDisk_SDSSDX120GG25_120823400863-part3 -> ../../sda3
    lrwxrwxrwx 1 ... ata-SanDisk_SDSSDX120GG25_120823402786 -> ../../sdb
    lrwxrwxrwx 1 ... ata-SanDisk_SDSSDX120GG25_120823402786-part1 -> ../../sdb1
    lrwxrwxrwx 1 ... ata-SanDisk_SDSSDX120GG25_120823402786-part2 -> ../../sdb2
    lrwxrwxrwx 1 ... ata-SanDisk_SDSSDX120GG25_120823402786-part3 -> ../../sdb3

    Таким образом, все компоненты имени устройства в модели by-id не определяются условиями его подключения и не вычисляются по каким-то заумным правилам, а определяются производителем и жёстко прошиты в "железе". Более того, они практически не зависят и от операционной системы -- в этом легко убедиться, сравнив имена устройств by-id в Linux'е и DragonFly. А потому эта модель является наиболее однозначной для именования устройств. Что немаловажно, она строится по понятной человеку логике и относительно легко укладывается в нормальной голове. Не случайно именно она принята по умолчанию, например, в модуле дисковой разметки системы YaST2 дистрибутива openSUSE -- самом мощном и логичном из высокоуровневых инструментов этого назначения.

    Алексей Федорчук

    http://alv.me/?p=4630


    Категория: Linux и не только | Просмотров: 448 | Добавил: laptop | Рейтинг: 5.0/1
    Всего комментариев: 0
    Добавлять комментарии могут только зарегистрированные пользователи.
    [ Регистрация | Вход ]
    Волк слабее льва и тигра, но в цирке волк не выступает!
    Волк слабее льва и тигра, но в цирке волк не выступает!
    Волк - единственный из зверей, который может пойти в бой на более сильного противника.
    Если же он проиграл бой, то до последнего вздоха смотрит в глаза противника. После этого умирает...

    Праздники сегодня

    Погода
    Погода в Нью-Йорке Погода в Бреcте
    Поиск
    Календарь
    Архив записей
    Друзья сайта
  • Официальный блог
  • JEEP - the best! Mercedes - the best! Автомобильный портал города Бреста: технические характеристики с фото, авторынок, автоспорт...
    Наша кнопка
    IT новости с моего лаптопа...

    Внимание!
    Администратор сайта laptop.ucoz.ru не несет ответственности за содержание рекламных объявлений. Все используемые на сайте зарегистрированные товарные знаки принадлежат своим законным владельцам! Используемая со сторонних источников информация публикуется с обязательными ссылками на эти источники.
    Copyright Valeri N.Kravchuk © 2007-2019