Русские Блоги
Далее разбираемся в блочных устройствах операционной системы Linux
В этой статье мы дополнительно проанализируем блочные устройства Linux, надеясь дать вам более глубокое понимание деталей реализации блочных устройств.。
Фактически, блочное устройство или драйвер блочного устройства могут быть очень удобно реализованы в операционной системе Linux. В Linux такими блочными устройствами являются хорошо известные RAID, multipathing и Ceph RBD. Его характеристика есть в операционной системе /dev В каталоге будет создан файл. Различные типы блочных устройств, показанные на рисунке 1, включают обычные блочные устройства SCSI и блочные устройства логических томов LVM, которые по сути являются блочными устройствами.Разница заключается в различной бизнес-логике и именах.
Принцип реализации блочного устройства
Вышеупомянутая программа блочного устройства может быть скомпилирована в модуль ядра. После загрузки модуля ядра с помощью команды insmod вы можете /dev Под каталогом вы видите файл с именемsbullaЗаблокировать устройство.
Сложность блочного устройства заключается в большом разнообразии шин, а также в множестве основных типов драйверов. Сложность всей системы заключается в инициализации блочного устройства. После включения устройства очень сложно связать его с ядром Linux и представить его пользователю. На рис. 2 показан снимок экрана содержимого шины Linux, представленного этим номером. Блочное устройство может быть расположено в любом месте шины на рисунке.
Поскольку эта часть содержимого сама по себе очень сложна, в этой статье не приводятся подробности содержимого, относящиеся к работе по инициализации устройства. Впоследствии этот номер будет вводить связанный контент отдельно. Сегодня эта статья в основном представляет связанное содержимое блочного устройства и уровня базового драйвера в более интуитивно понятной форме с помощью нескольких примеров.
В качестве примера возьмем блочное устройство SCSI, хотя имя отображается в / dev.sdXБлокировать устройства, но основная разница между драйверами очень велика. Мы знаем, что устройства SCSI могут быть подключены к хосту разными способами:
Различные блочные устройства в Linux
DRBD
Номер DRBD был представлен в предыдущей статье, и он называется распределенным реляционным блочным устройством (то есть блочным устройством распределенной репликации). DRBD можно понимать как сетевой RAID1, то есть его блочные устройства существуют на двух серверах одновременно, и существует взаимосвязь спаривания. Когда делается запрос на запись в одно из блочных устройств, DRBD копирует данные в блочное устройство на другом сервере с помощью внутренней логики. Таким образом повышается доступность блочного устройства.Когда один из серверов не работает, другой сервер все еще может предоставлять мне услуги.
Подобно NBD, разница между DRBD и другими блочными устройствами заключается в его процедуре обработки очереди. В DRBD это процедура drbd_make_request. Вы можете проанализировать конкретную реализацию этой процедуры самостоятельно.
Помимо типов блочных устройств, представленных выше, существует множество типов блочных устройств, таких как LVM и multipath. Из-за ограниченного объема в данной статье он пока не рассматривается, а будет представлен позже.
Обработка запроса на блокировку устройства
В предыдущей статье мы упоминали псевдофайловую систему блочного устройства, и мы знаем, что псевдофайловая система в конечном итоге вызовет общий блочный уровень. generic_perform_write функция. Затем в этой статье будет проанализирована конкретная реализация этой функции, чтобы каждый имел более глубокое представление о процедурах в группе запросов, упомянутой выше. Ниже приведен конкретный код функции. В этой статье удаляются некоторые некритические части кода и сохраняется основной код.
Можно видеть, что после того, как запрос достигает уровня общего блока, вызывается указатель функции make_request_fn очереди запросов, и эта функция, наконец, вызывает подпрограмму, которую мы зарегистрировали при создании блочного устройства. Это не одна и та же функция. Здесь мы должны обратить внимание на один момент. Мы представим эту часть более подробно позже. Поскольку здесь все сложнее, здесь можно найти информацию об общем планировании ввода-вывода блочного уровня.
С помощью приведенного выше описания у нас есть более глубокий уровень обработки запросов ввода-вывода, то есть от уровня пользователя до уровня псевдофайловой системы, а теперь и до общей очереди запросов на уровне блоков. Конечно, последнее должно обрабатываться в нашей зарегистрированной программе. Здесь различие между различными типами блочных устройств и разная логика обработки разных типов блочных устройств. Для устройств SCSI он отправляется на сторону Target для обработки по протоколу SCSI, а для устройств NBD он отправляется на сторону сервера для обработки через сеть.
Хорошо, давайте приступим к делу сегодня, и мы представим основную функцию планирования операций ввода-вывода для блочных устройств.
Настольная книга по Linux/Блочные устройства
Содержание
Получение общей информации [ править ]
Вывести список действительных в данный момент блочных устройств:
… Включая информацию о подключенных файловых системах:
Вывести списки блочных устройств по идентификатору, способу подключения, метке и UUID (в последних двух случаях — только для тех устройств, где они назначены):
Вывести отдельные метаданные (UUID, метка, тип ФС, etc. ) блочных устройств:
Вывести сведения о разделах доступных носителей:
… Таблицу разделов, используемую ядром (можно использовать partprobe(8) для обновления): [1]
… Более подробную информацию о разделах устройства /dev/ sdX :
Вывести таблицу разделов MBR устройства /dev/ sdX в текстовом представлении:
… В виде, пригодном для последующего восстановления:
… Скопировать таблицу с /dev/ sdX на /dev/ sdY :
Скопировать главную загрузочную запись с устройства /dev/ sdX в файл sdX.mbr :
Считать данные температурных датчиков устройств:
… Получить эти же данные с hddtemp(8), работающего в режиме демона и обслуживающего запросы на порту 7634 :
Образы [ править ]
Снять образ устройства /dev/ sdX в файл image :
Восстановить содержимое устройства /dev/ sdX из файла image (осторожно! очевидно, эта команда приведет к потере всех находящихся на устройстве данных):
Записать образ image на DVD в приводе /dev/ sr3 :
Горячее подключение [ править ]
Обнаружить и инициализировать новое устройство на порту hostA :
Удалить из системы устройство /dev/ sdX :
Проверка состояния [ править ]
Измерить производительность устройства /dev/ sdX :
Запустить процедуры самодиагностики S.M.A.R.T. для устройства /dev/ sdX :
LVM [ править ]
Вывести информацию об известных физических томах, группах, и логических томах LVM:
… Только о логических томах группы vgfoo :
Активировать логический том lvbar группы vgfoo :
… Все тома группы vgfoo :
Запретить (разрешить) запись на логический том lvbar группы vgfoo :
… Удалить (осторожно! перед выполнением проверьте, что группа не содержит каких-либо имеющих значение данных):
Создать логический том lvbar объемом 4880 MiB в группе vgfoo :
… Удалить (осторожно! перед выполнением проверьте, что том не содержит каких-либо имеющих значение данных):
Перенести данные физического тома /dev/ sdY2 на другие физические тома группы:
… На физический том /dev/ sdX4
… Исключение из группы физического тома /dev/ sdY2 :
… Включение в группу физического тома /dev/ sdZ :
Блочное устройство linux что это
Любое устройство, подключенное к компьютеру, имеет свое назначение, и блочные устройства в большинстве своем предназначаются для хранения информации. Как организована работа с блочными устройствами в Linux?
Во-первых, следует определиться с типами блочных устройств. Их следует поделить на две категории: к первой отнесем логические (виртуальные) устройства (loop-устройства, software RAID-устройства, устройства Volume Management, поддержка различных таблиц разделов), ко второй категории – физические устройства (SCSI диски и CD-ROM’ы, IDE-диски, USB-storage, RAM-диск).
Виртуальные устройства являются на самом деле просто оберткой, дополнительным слоем. В реальности драйверы логических устройств не работают с периферийными устройствами напрямую, они лишь переадресовывают запросы на драйверы других логических или физических устройств.
Драйверы физических устройств работают совместно с драйверами контроллеров, позволяя производить доступ к соответствующим устройствам на блочном уровне и предоставляя тем самым фактически прямой доступ к носителю – но, поскольку в большинстве случаев дисковые устройства имеют значительный объем, они часто делятся на разделы. Раздел является постоянным непрерывным фрагментом дискового пространства, местоположение которого на жестком диске записано в специальной области диска – таблице разделов.
Существует множество различных форматов разбиения диска на разделы – например, DOS partition table, BSD disklabels, UnixWare slices и многие другие. Как правило, во всех случаях соответствующая спецификация предусматривает возможность перечисления ограниченного количества разделов путем указания номеров первой и последней дорожек, занимаемых каждым из разделов. Каждый раздел видится как отдельное блочное устройство.
Когда драйвер блочного устройства, поддерживающего разбиение на разделы, в процессе загрузки или работы обнаруживает обслуживаемое им устройство, он считывает с него таблицу разделов, определяет ее разновидность и составляет таблицу разделов, запоминая начало и конец каждого из разделов. Впоследствии, если какая-либо программа производит обращение не непосредственно к физическому устройству, а к разделу на этом устройстве, драйвер с использованием построенной таблицы разделов определяет реальный адрес блока, над которым нужно произвести запрошенную операцию ввода/вывода.
Особой разновидностью раздела можно назвать расширенный (extended) раздел DOS. Расширенный разделы DOS может быть разбит на произвольное количество вложенных разделов, но в настоящий момент без использования LVM ядро Linux поддерживает до 63 разделов на IDE-диске и до 15 разделов на SCSI-диске. Такое ограничение связано с распределением мажоров и миноров блочных устройств.
Когда используется разбиение диска на разделы с использованием таблицы разделов DOS, следует помнить, что на жестком диске может быть не более 4 первичных разделов. Если администратору нужно, чтобы на жестком диске было более 4 разделов, необходимо объявить один из первичных разделов как расширенный раздел. Первичные разделы при использовании таблицы разделов DOS нумеруются от 1 до 4, логические разделы нумеруются начиная с 5, вне зависимости от количества первичных разделов. Только один из первичных разделов может быть объявлен расширенным.
Рассмотрим вывод команды fdisk, которая обычно используется в Linux для разбиения диска на разделы:
Как видно, на жестком диске IDE созданы 6 разделов, из них 4 первичных (разделы с номерами от 1 до 4) и два логических раздела с номерами 5 и 6, созданных внутри extended-раздела hda4.
Таблица разделов диска не может быть изменена в том случае, если хотя-бы один из разделов этого диска используется. В этом случае ядро продолжает использовать “старую” разметку (с которой оно работало до изменения), а изменения записываются на диск и вступают в силу после перезагрузки компьютера.
Например, эти данные могут быть использованы для восстановления таблицы разделов, если системный администратор по ошибке ее исправил.
Интересной особенностью таблицы разделов диска является то, что она не всегда изменяема. Это приводит к тому, что во многих случаях невозможно изменить размер какого-либо раздела или внести какие-либо другие изменения в таблицу разделов без перезагрузки – т.е. системный администратор может делать любые изменения, но они вступят в силу только после перезагрузки системы.
14.1. Распределение мажоров и миноров IDE дисков
IDE-диски в настоящее время наиболее часто используются в офисных и домашних компьютерах, поэтому знать особенности распределения мажоров и миноров для этих типов устройств достаточно важно. IDE-устройства отличаются низкой ценой и неплохой скоростью передачи данных, но у этой шины есть архитектурные недостатки – например, все устройства работают со скоростью самого медленного из них, на один шлейф (на один канал) можно подключить только 2 устройства.
Всем устройствам, находящимся на одном канале IDE, присвоен один мажор. В настоящий момент ядро Linux выделяет для каждого устройства 64 минора, из которых первый минор зарезервирован для всего диска, и 63 минора остается для идентификации разделов. Таким образом, для IDE-дисков мажор идентифицирует канал, а по минору можно определить номер устройства на канале (режим master/slave) и номер раздела. Более детально это можно увидеть в следующей таблице:
Таблица 1. Распределение номеров устройств для IDE-дисков
| Канал | Устройство | Раздел | Major number | Minor number | Имя в /dev |
|---|---|---|---|---|---|
| 1 | 1 | Весь диск | 3 | 0 | /dev/hda |
| Раздел 1 | 1 | /dev/hda1 | |||
| Раздел 2 | 2 | /dev/hda2 | |||
| Раздел 3 | 3 | /dev/hda3 | |||
| Раздел 4 | 4 | /dev/hda4 | |||
| . | . | . | |||
| Раздел 63 | 63 | /dev/hda63 | |||
| 2 | Весь диск | 64 | /dev/hdb | ||
| Раздел 1 | 65 | /dev/hdb1 | |||
| Раздел 2 | 66 | /dev/hdb2 | |||
| Раздел 3 | 67 | /dev/hdb3 | |||
| . | . | . | |||
| Раздел 63 | 127 | /dev/hdb63 | |||
| 2 | 1 | Весь диск | 22 | 0 | /dev/hdc |
| Разделы | 1-63 | /dev/hdc[1..63] | |||
| 2 | Весь диск | 64 | /dev/hdd | ||
| Разделы | 65-127 | /dev/hdd[1..63] |
По таблице становится видно, что на каждый 64-й минор происходит смена физического диска. Драйвер IDE в текущей версии ядра Linux поддерживает до четырех каналов IDE – т.е. до 8 устройств, по два устройства на канал..
Рекомендации, которую можно дать владельцам компьютеров с интерфейсом IDE: устройства по возможности рекомендуется держать на разных каналах. Если нет свободных каналов, то “быстрые” устройства лучше подключать на один канал, медленные – на другой.
14.2. Распределение мажоров и миноров для SCSI-дисков
Шина SCSI свободна от некоторых недостатков IDE, например количество устройств на одном канале может быть 15 (на самом деле 16, но одним устройством считается сам контроллер), все SCSI устройства работают на своей максимальной скорости, и ограничены только возможностями шины и контроллера – но SCSI-устройства и дороже, и поэтому шина SCSI используется в основном на серверах и рабочих станциях. Для SCSI-дисков ситуация немного меняется – мажоры не привязаны к контроллерам (т.е. один major number может использоваться дисками с разных хост-адаптеров). На каждом SCSI-диске система поддерживает до 16 разделов, а нумерация дисков производится в порядке их подключения по схеме, аналогичной IDE-дискам – но только переход на следующий диск происходит на каждом 16-м миноре (т.е. разделы на SCSI-дисках нумеруются от 1 до 15). Увидеть это можно в следующей таблице и листинге /dev :
Таблица 2. Распределение номеров устройств для SCSI-дисков
| Номер диска в порядке подключения | Major number | Minor number | Раздел | Имя файла |
|---|---|---|---|---|
| 1 | 8 | 0 | Весь диск | sda |
| 1 | Первый первичный | sda1 | ||
| 2 | Второй первичный | sda2 | ||
| 3 | Третий первичный | sda3 | ||
| 4 | Четвертый первичный | sda4 | ||
| 5 | Первый логический | sda5 | ||
| . | . | . | ||
| 15 | Одиннадцатый логический | sda15 | ||
| 2 | 8 | 16 | Весь диск | sdb |
| 17 | Первый первичный | sdb1 | ||
| 18 | Второй первичный | sdb2 | ||
| 19 | Третий первичный | sdb3 | ||
| 20 | Четвертый первичный | sdb4 | ||
| 21 | Первый логический | sdb5 | ||
| . | . | . | ||
| 31 | Одиннадцатый логический | sdb15 |
14.3. Устройства SATA и переход с IDE на PATA
SATA, «осовремененная» версия интерфейса IDE, по своей структуре приблизилась к подсистеме SCSI. Поэтому в целях унификации подсистемы ввода-вывода в ядре Linux поддержка SATA была реализована через интерфейс SCSI, соответственно SATA-диски и контроллеры видятся ядром (и пользователем) как SCSI-устройства.
А говоря проще, это означает следующее – если у вас новый дистрибутив или имеются SATA-диски, вы можете смело работать со всеми дисками как со SCSI-устройствами.
14.4. Logical Volume Manager
Использование таблиц разделов для управления дисковым пространством – достаточно часто используемое решение. К сожалению, оно не свободно от определенных недостатков – например, нет возможности расширить раздел или уменьшить его размер, нет возможности создать один раздела на нескольких дисках и т.д. Решить эту задачу призван LVM (Logical Volume Manager).
LVM работает следующим образом: пользователь может пометить какие-либо блочные устройства как разделы, используемые LVM. Каждое из таких помеченых блочных устройств (их называют физическими томам,и или physical volumes) может быть присоединено к какой либо группе логических томов (logical volume groups). Внутри групп логических томов могут создаваться уже собственно логические тома (logical volumes). Дисковое пространство любого физического тома из некоторой группы может быть выделено любому логическому тому из этой группы. Реализовано это через так называемые “экстенты” (extents) дискового пространства. Физические тома LVM разбиваются на экстенты, после чего из экстентов и составляются логические тома. Именно за счет этого можно динамически менять конфигурацию дискового пространства – экстент может быть удален из одного тома, и добавлен к другому. Каждый объект LVM – будь то логический том, физический том или группа томов, имеет свой уникальный идентификатор.
Осуществляется это комплексно драйвером device mapper и специализированными программами из пакета lvm2. Эти программы читают файлы конфигурации и служебную информацию из заголовков физических томов, и на основании этой информации сообщают драйверу инструкции о том, из каких фрагментов каких блочных устройств каким именно образом должны быть скомбинированы логические тома, после чего драйвер для каждого логического тома создает отдельное блочное устройство. При обращении к такому блочному устройству device mapper определяет, на основании ранее переданных параметров к какому блоку какого блочного устройства на самом деле должен быть переадресован запрос, и запрашивает соответствующее блочное устройство для окончательного выполнения операции, после чего возвращает результат выполнения операции (прочитанные данные, сообщение об ошибке, код завершения операции) обратившейся программе.
Использование LVM позволяет гибко управлять распределением дискового пространства и избежать ограничений, связанных с классическим распределением дискового пространства путем создания разделов на жестких дисках. Единственное правило, которое я бы советовал соблюдать при использовании LVM – не создавать корневой раздел системы на логическом томе LVM: инициализации тома LVM, на котором находится корневая файловая система, необходимо вмешательство некоторых утилит, которые находятся на еще не смонтированной корневой файловой системы. Это решаемая проблема, но она потребует некоторого опыта.
Ниже идет пример создания и инициализации физического тома, группы томов и примеры нескольких операций с логическими томами. На первом фрагменте протокола продемонстрирована инициализация таблицы разделов для использования LVM. Порядок действий для использования LVM в общем случае следующий: один или несколько разделов жесткого диска с помощью fdisk помечаются как разделы LVM. Затем эти разделы инициализируются и передаются в группы томов, после чего их дисковое пространство можно использовать для создания логических томов:
В приведенном выше выводе fdisk видно, что на IDE-диске primary slave создан один раздел типа LVM (код типа раздела 0x8E). В следующем листинге показан процесс инициализации физического тома и создания группы томов aurora, в которую включается инициализированный командой pvcreate физический том /dev/hdb1 :
Третий фрагмент демонстрирует создание нескольких томов и изменение размеров томов, проделанное с помощью LVM. В этом примере создается логический том размеров в 20GB, затем размер этого тома увеличивается до 30GB, создается еще один логический том, и после этого оба созданных логических тома удаляются.
Еще один фрагмент демонстрирует удаление группы томов и очистку физического тома:
Таким образом, возможности LVM позволяют системному администратору максимально эффективно использовать дисковое пространство, оперативно реагируя на меняющиеся условия эксплуатации. Еще одной интересной возможностью LVM является так называемый multipath I/O. В случае активации соответствующей опции в ядре device mapper знает о том, что физический том с некоторым UUID может быть доступен через несколько контроллеров, и в случае отказа одного контроллера динамически происходит переключение ввода-вывода на другой. Опытные системные администраторы также оценят такую возможность, как создание снимка (snapshot) логического тома: при создании снимка создается моментальная копия логического тома, которая начинает «жить» независимо от того тома, на основе которого она была создана:
14.5. Sotware RAID
Ядро Linux содержит средства для организации software raid (программных RAID-устройств). Эта возможность поддерживается драйвером устройств md. В отличие от device mapper, драйвер md умеет работать в “самостоятельном” режиме, получая конфигурацию из параметров, которые пользователь указал ядру при загрузке системы, что позволяет организовывать загрузку системы с RAID-устройств. Все устройства md имеют мажор 254 и миноры от 0 и до 16383.
В отличие от LVM, основной задачей которого является динамическое распределение дискового пространства (деление разделов на фрагменты и построение из фрагментов новых блочных устройств), задачей подсистемы RAID является построение новых блочных устройств путем объединения существующих.
Каждое из устройств, входящих в создаваемый дисковый массив, может определенным образом помечаться. Впоследствии эти метки (их также называют array superblocks) используются для повторной сборки массива. В частности, например, суперблок массива содержит его уникальный идентификатор, который можно использовать при сборке ранее созданного массива после перезагрузки. Если программный RAID-массив был помечен в процессе создания (т.е. на нем был создан суперблок массива), это дает возможность автоматической сборки массива вне зависимости от того, поменялся или нет порядок следования устройств. Например, такая необходимость может возникнуть в ситуации, когда порядок нумерации блочных устройств изменился – например, один из SCSI-дисков, участвовавших в построении массива, был удален.
Естественно, суперблок не является обязательным – то есть можно создавать массивы без суперблока, но управления ими может быть затруднено вследствие необходимости «руками» контролировать корректность указания устройств при переконфигурации массива.
Из интересных особенностей драйвера md стоит отметить то, что он поддерживает разбиение md-устройств на разделы, при этом минорные номера присваиваются разделам аналогично тому, как они присваиваются разделам на дисках IDE, т.е на каждом RAID-устройстве можно создать до 63 разделов. Определить минор раздела, созданного на RAID-устройстве, можно с помощью вычисления значения следующего выражения: 64 * N + M, где N – это номер массива (номер RAID-устройства) из диапазона 0. 255, а M – это номер раздела из диапазона 1. 63.
Следует сказать, что по умолчанию в большинстве дистрибутивов специальные файлы для разделов на md-устройствах не создаются, и их необходимо создать вручную командой mknod. В настоящий момент оптимальным, наверное, следует считать комбинирование использования LVM и md, что позволяет достигнуть надежности за счет дублирования данных средствами md, и гибкости распределения дискового пространства за счет возможностей LVM.
Драйвер md хорошо подходит для создания RAID-устройств уровней 0, 1 или 0+1, но не будет являться оптимальным вариантом в случае использования, например RAID уровня 5 (чередование данных по устройствам с вычислением контрольной суммы и кодом исправления ошибок), поскольку это создаст значительную нагрузку на процессор при большом объеме передаваемых данных. Возможно, что в таких случаях стоит подумать о приобретении аппаратного контроллера RAID – например, HP NetRaid (сделан на основе AMI MegaRAID) или Compaq Smart Array (сейчас называется HP Smart Array).
В первом примере будем считать, что на жестком диске hdb создано два раздела, с которыми мы и будем экспериментировать. Для начала необходимо произвести инициализацию md-устройства. Соответственно, для успешной необходимо указать тип RAID-массива, специальный файл md-устройства, которое мы хотим инициализировать, и список блочных устройств, на которых будет располагаться получившийся массив:
Последняя команда демонстрирует активизацию массива путем указания имени md-устройства и нескольких блочных устройств, на которых оно базируется. Все остальные параметры (размеры блоков, разновидность RAID и т.д.) утилита mdadm извлекла из суперблока массива. Как уже отмечалось, суперблок массива содержит еще и уникальный идентификатор массива, что дает возможность проидентифицировать каждое исходное блочное устройство на предмет его принадлежности к какому-либо массиву. Ниже приведен пример вывода утилиты mdadm, демонстрирующий как можно получить некоторые полезные данные о массиве, а строка, содержащая UID массива выделена жирным текстом:
Впоследствии этот идентификатор может быть использован в файле конфигурации для утилиты mdadm. В конфигурационном файле /etc/mdadm.conf можно указать список устройств и правила их построения, после чего описанные в нем md-устройства будут автоматически собираться и разбираться без указания списка исходных устройств:
Системный администратор, который хочет расположить корневую файловую систему на md-устройстве, должен указать ядру при загрузке какие именно физические блочные устройства должны входить в md-устройство, на котором содержится корневая файловая система. Обычно это делается путем загрузки ядра командной строкой с опциями следующего вида:
Данный пример приведен скорее как иллюстративный, поскольку в зависимости от опций, использованных при создании RAID-устройства, на котором расположена корневая файловая система, командная строка ядра может меняться. В современных дистрибутивах при необходимости инициализации md-устройств для загрузки системы, как правило код и утилиты инициализации устройства помещаются в initrd.
Суперблок массива записывается не в начале блочного устройства, а ближе к его середине или концу. Сделано это было для того, чтобы можно было создать RAID-массив с boot-сектором, который сможет быть прочитан не только ядром Linux с драйвером md, но и базовым загрузчиком BIOS, вследствие чего можно объединить в RAID-массив не разделы жестких дисков, а непосредственно физические диски. Тогда загрузчик, установленный в начало RAID-устройства, окажется установленным в начало жесткого диска, после чего можно использовать при загрузке ядра следующую командную строку:
Драйвер md также поддерживает возможность задания hotswap-устройств для массивов, т.е. резервных устройств, которые могут быть активизированы в при сбое одного из основных устройств в массиве.
Поддержка устройств software RAID в Linux дает возможность создавать серверы с высокой отказоустойчивостью и быстродействием.
14.6. Device mapper
В ядрах линейки 2.6 появилась еще одна подсистема по некоторым функциям аналогичная подсистеме MD, и называемая device-mapper. Это модульная компонентная подсистема, позволяющая с помощью специальных команд создать одно блочное устройство из нескольких кусков других блочных устройств, а также определить правила, по которым производится запись на эти «нижележащие» блочные устройства.
LVM работает именно через подсистему device mapper, и на самом деле все утилиты LVM на самом деле просто передают инструкции о том из каких фрагментов каких блочных устройств состоит какой том LVM в драйвер device mapper, в каком порядке осуществляется запись и чтение данных, и впоследствии при записи на том LVM или чтении с него, работа на самом деле ведется с устройствами, обслуживаемыми драйвером device mapper, который и делает всю работу.
Данная многоуровневая архитектура позволяет значительно упростить и таким образом значительно повысить стабильность работы системы, поскольку реализация нескольких небольших узкофункциональных компонентов в общей сложности содержит меньше ошибок, чем реализация всех этих функций в одной подсистеме.
14.7. Host-RAID, или дешевых RAID-контроллеров не бывает
Сегодня даже для дешевых современных материнских плат фирмы-производители часто декларируют «аппаратную поддержку RAID» и у многих пользователей этот факт вызывает недоумение – как же так, мой Linux не умеет работать с RAID?!
На самом деле все проще – задекларированная и разрекламированная поддержка RAID-массивов на материнских платах для офисных и домашних компьютеров – это миф.
Вся поддержка RAID в таких «контроллерах» на самом деле представляют собой просто небольшое расширение в BIOS и без специальных драйверов в 32/64-битных операционных системах такие контроллера не работают, а все функции RAID для них выполняются драйвером. Если в Windows для каждого из таких контроллеров фирма-производитель пишет драйвер, то в Linux ситуация немного иная.
Для реализации возможности работы с такими псевдо-RAID контроллерами (иногда называемыми fake-RAID) была разработана утилита dmraid. При запуске она сканирует жесткие диски в поисках специальных блоков (функционально аналогичных суперблокам уже знакомых нам md-устройств), записываемых такими fake-RAID контроллерами, и если ей удалось распознать формат этого специального блока, то dmraid инструктирует подсистему device-mapper о том, в каком порядке следует считывать блоки с жестких дисков.
После этого device-mapper создает блочное устройство, при записи или чтение данных с которого данные автоматически читаются и пишутся так, как сделал бы это драйвер от производителя материнской платы или контроллера.