Поскольку протокол SCSI применяется для соединения с периферийными устройствами, такими как жёсткие диски, некоторое базовое понимание относительно работы этих устройств послужит пониманию всей подсистемы SCSI.

Все представленные в этой главе команды и примеры не зависят от дистрибутива и могут исполняться в любой операционной системе Linux, например, в Debian, Ubuntu, Red Hat и Fedora. Присутствуют всего лишь несколько ссылок на исходный код ядра. Если вы пожелаете выгрузить исходный код ядра, вы можете выполнить это с https://www.kernel.org.

В ядре присутствуют различные подсистемы, такие как system call interface (интерфейс системных вызовов), VFS (виртуальная файловая система), process and memory management (управление процессом и памятью), а также network stack (сетевой стек). На протяжении данной книги мы строго держим в фокусе структуры и логические элементы, которые выступают частью иерархии ввода/ вывода в Linux. Тем не менее, на практике, собственно процесс считывания и записи в устройство хранения обязан проходить по большинству этих подсистем. Как мы уже наблюдали, альфой и омегой нашего стека ввода/ вывода являются уровни абстракции, однако этот абстрактный подход не ограничивается устройствами хранения. Для нашего ядра диск это всего лишь несколько фрагментов аппаратных средств, которыми оно обязано управлять. Если бы для различных типов устройств имелись бы уникальные системы управления, это бы в результате приводило бы к чрезмерному раздутию фрагментов кода. Естественно, к различным типам устройств относятся по- разному, так как они способны обладать различными ролями, но для конечного пользователя должно иметься общее абстрактное представление о соответствующей структуре системы.

Для достижения единообразия Модель устройства Linux выделяет общие атрибуты операций устройств, выполняет их абстрактное представление и реализует такие общие атрибуты в своём ядре, предоставляя единый интерфейс для вновь добавляемых устройств. Это намного упрощает процесс разработки драйвера и превращает его в более гладкий, поскольку разработчику всего лишь требуется ознакомиться с таким интерфейсом.

Основной поставленной для Модели устройств целью является сопровождение внутренних структур, которые точно представляют состояние системы и ей конфигурацию. Сюда входят важные сведения, такие как присутствие устройств, связанных с ними шин и драйверов, а также общая иерархия и структура шин, устройств и драйверов в общей системе. Чтобы отслеживать эту информацию, модель устройства применяет следующие логические объекты для сопоставления их с физическими аналогами:

Модель устройств представляет универсальный механизм представления любых устройств в системе и работы с ними. Как пояснялось в Главе 1 этой книги, само ядро предоставляет некое окно экспорта сведений о различных подсистемах ядра через VFS. Всё представление Модели устройств в пространстве пользователя можно просматриваться через Sysfs VFS. Эта файловая система Sysfs монтируется в каталоге /sys, что показано на приводимом ниже рисунке:

Эти каталоги содержат следующие сведения:

Существует взаимная зависимость между структурами данных ядра в описанной модели и подкаталогами в Sysfs VFS. В модели устройства присутствует ряд структур, которые обеспечивают связь между драйвером устройства и соответствующим аппаратным устройством. Мы не собираемся исследовать эти структуры, но, чтобы вы знали, базовая структура Модели устройства Linux — это kobject. Представляйте себе kobject как связующее звено, которое скрепляет собственно Модель устройства и интерфейс Sysfs. Вот, на рисунке 7.2, показаны структуры более высоких уровней модели:

А это сам Рисунок 7.2:

Подводя итог, Модель устройств Linux классифицирует аппаратные устройства и реализует абстракцию через некий набор стандартных структур данных и интерфейсов. Данную Модель можно просматривать через содержимое файловой системы Sysfs. Все представленные в Sysfs логические элементы тесно взаимосвязаны со своими действительными физическими реализациями. Давайте двинемся далее и изучим более подробно архитектуру подсистемы SCSI.

Когда люди говорят о SCSI (произносится: &СКАЗи&), они могут иметь в виду пару вещей:

Долгое время SCSI была основной технологией для шин ввода/ вывода в компьютерах. SCSI определяет как интерфейс, так и протокол данных для подключения различных типов устройств к компьютеру. В качестве среды SCSI определяет шину для передачи данных. Как протокол, она определяет каким образом устройства взаимодействуют друг с другом через такую шину SCSI.

Изначально соединение периферийных устройств достигалось через параллельную шину SCSI. С годами параллельная шина SCSI вышла из моды и была заменена последовательными интерфейсами. Наиболее распространёнными среди этих интерфейсов являются SAS (Serial Attached SCSI, SCSI с последовательным интерфейсом) и SCSI over Fibre Channel (SCSI поверх Fiber Channel). Последовательные интерфейсы предоставляют намного более высокие скорость передачи данных и надёжность. Существует также реализация протокола SCSI поверх TCP/IP, носящая название iSCSI (Internet SCSI).

Мы будем продолжать сосредотачиваться на вопросах со стороны Linux и обсудим организацию подсистемы SCSI в общей иерархии ввода/ вывода. Стандарт SCSI определяет наборы команд для широкого спектра устройств, причём не только для жёстких дисков. Это превращает SCSI в силу самого факта в стандарт для устройств хранения, доступ к которым осуществляется через протокола SATA, SAS или Fibre Channel.

Подсистема SCSI пользуется архитектурой из трёх уровней. Самый верхний уровень представляет наивысший интерфейс ядра для приложений конечного пользователя. Уровень в середине предоставляет некие распространённые службы для лежащих выше и ниже уровней своего стека SCSI. На самом дне расположен нижний уровень. Такой нижний уровень содержит действительные драйверы, которые взаимодействуют с лежащими в основе физическими устройствами. Всякая вовлекаемая в подсистему SCSI операция на каждом из трёх уровней пользуется одним драйвером. Рисунок 7.3 высвечивает эту многоуровневую архитектуру подсистемы SCSI:

В наших последующих разделах данные три уровня поясняются слегка более подробно.

 

Верхний уровень

Upper level (верхний уровень) содержит драйверы конкретных типов устройств, которые наиболее близки к приложениям уровня пользователя. Эти драйверы верхнего уровня обеспечивают взаимодействие между пространством пользователя и пространством ядра. Наиболее часто применяемые драйверы верхнего уровня включают в свой состав:

После просмотра названий этих драйверов не удивительно, что имена устройств соответствующих типов сокращаются с применением в качестве префикса самого драйвера, к примеру sda. Верхний уровень принимает запросы от более высоких уровней общего стека хранения, скажем, от VFS, и преобразует их в эквивалентные запросы SCSI при помощи промежуточного и нижнего уровней. По завершению команд SCSI драйверы верхнего уровня информируют свои более высокие уровни. Обобщённый драйвер SCSI, sg, делает возможной непосредственную отправку команд SCSI в устройства SCSI, минуя уровень файловой системы.

Драйверы дисков SCSI верхнего уровня реализованы в /linux/drivers/scsi/sd.c. Драйверы дисков SCSI верхнего уровня самостоятельно инициализируются посредством вызова register_driver для регистрации в качестве блочных устройств, предоставляя набор функций через соответствующую функцию scsi_register_driver для предоставления всех устройств SCSI.

 

Промежуточный уровень

Mid layer (промежуточный уровень) общий для всех операций SCSI и содержит собственно ядро необходимой поддержки SCSI. Этот промежуточный уровень объединяет верхний и нижний уровни, определяя внутреннее взаимодействие и предоставляя общие службы драйверам верхнего и нижнего уровней. Он контролирует управление очередями команд SCSI, обеспечивает действенную обработку ошибок и упрощает функции управления питанием.Драйверы верхнего и нижнего уровней не способны работать без предоставляемых промежуточным уровнем функциональных возможностей.

Обобщённый драйвер промежуточного уровня реализован в linux/drivers/scsi/scsi.c. Промежуточный уровень осуществляет абстрагирование реализации драйверов нижнего уровня и преобразует команды верхнего уровня в эквивалентные запросы SCSI. Этот промежуточный уровень к тому же реализует очередь команд. После получения запроса с верхнего уровня промежуточный уровень ставит запросы в очередь на обработку. После обработки соответствующего запроса он получает отклик с нижнего уровня и уведомляет верхний уровень. Если время запроса истекло (timed out), промежуточный уровень обязан осуществить обработку ошибок, либо повторно отправить этот запрос.

Существует пара важных команд, посредством которых промежуточный уровень служит в качестве моста между верхним и нижним уровнями, sd_probe и sd_init. В процессе инициализации драйвера и при каждом подключении нового устройства SCSI к системе, функция sd_probe играет критически важную роль в определении того, будет ли данное устройство управляться дисковым драйвером SCSI или нет. Когда устройство подпадает в сферу применения, sd_probe вырабатывает новую структуру scsi_disk, которая будет служить в качестве представляющего его логического элемента. После получения запроса на считывание или запись с более верхних уровней общего стека хранения, скажем от файловой системы, соответствующая функция sd_init_command преобразует этот запрос в эквивалентную команду SCSI считывания или записи.

 

Нижний уровень

Lower-level drivers (драйверы нижнего уровня) наиболее близки к оборудованию. Именно эти драйверы служат для поддерживаемых операционной системы разнообразных адаптеров и контроллеров. Такие адаптеры или контроллеры зачастую именуются HBA (Host Bus Adapters, главными адаптерами шины). Такие драйверы нижнего уровня предоставляют действительную поддержку запускаемых в основе аппаратных платформ. Подобные драйверы нижнего уровня зависят от производителя и предоставляют интерфейс с лежащим в основе оборудованием. Например, lpfc это драйвер устройств для HBA Emulex. Необходимые драйверы нижнего уровня представлены в каталоге linux/drivers/scsi/.

Теперь давайте погрузимся глубже в то, каким образом подсистема SCSI способна классифицироваться как работающая внутри модели клиент- сервер.

Подсистема SCSI получает запросы с более верхних уровней общего стека хранения для отправки блоков данных устройства хранения или для их выборки. Когда приложение инициирует запрос считывания или записи, уровень SCSI обрабатывает такой запрос преобразуя его в эквивалентную команду SCSI. Подсистема SCSI не обрабатывает организацию и размещение блоков данных в своих устройствах хранения; это задание для более высоких уровней общего стека ввода/ вывода. SCSI отправляет блоки в целевое устройство, которым может быть либо отдельный диск, либо контроллер RAID (redundant array of independent disks, массива независимых дисков с избыточностью).

Поскольку уровень SCSI на стороне операционной системы открывает операцию на устройстве хранения, а это устройство хранения, в свою очередь, отвечает выполнением указанной операции, этот поток событий можно классифицировать как модель обмена клиент- сервер. В соответствии с манерой выражения SCSI эти две стороны именуются инициаторами (initiators) и целями (targets). Говорят, что инициирующая запрос операционная система хоста действует в качестве инициатора SCSI. Целевое устройство хранения, которое получает и обрабатывает этот запрос, называется целью SCSI.

Инициатор SCSI располагается в соответствующем хосте и вырабатывает запросы от имени более высоких уровней стека. Цель SCSI ожидает команды от инициатора, а затем выполняет запрошенную передачу данных. Должен существовать базовый транспортный механизм, обеспечивающий доставку команды SCSI от инициатора к цели. Именно это реализуется через транспортный уровень SCSI. Существует множество протоколов передачи, например SAS (Serial Attached SCSI) для непосредственно подключаемых дисков, а также Fibre Channel или iSCSI для являющихся частью SAN (Storage Area Network, сети хранения данных) целей SCSI. Взаимосвязь между инициатором SCSI и его целью показана на Рисунке 7.4:

Перейдём к схеме адресации.

 

Адресация устройства

Для идентификации устройств SCSI Linux применяет иерархическую схему адресации из четырёх частей. Такая комбинация четырёх номеров уникально идентифицирует местоположение устройства SCSI внутри системы. Если в командной строке вы выполните lsscsi или sg_map -x вы обнаружите что для представления в вашей системе устройства SCSI последовательность из четырёх номеров.

[root@linuxbox ~]# lsscsi
[0:0:0:0]    disk    ATA      SAMSUNG MZMTE512 400Q  /dev/sda
[4:0:0:0]    disk    ATA      ST9320320AS      SD57  /dev/sdb
[6:0:0:0]    disk    Generic- Multi-Card       1.00  /dev/sdc
[root@linuxbox ~]#
		

Эта четверная схема адресации носит название HBTL (Host, Bus, Target, LUN), а его поля определены следующим образом:

Наш следующий рисунок иллюстрирует данный механизм адресации и путь от хоста к диску SCSI. Обратите внимание, что существует относительный индекс цели SCSI, относящийся к контроллеру SCSI или HBA. Самой первой обнаруженной подключённой к host0 цели хранения SCSI назначается значение цели SCSI (относительный индекс) 0, затем 1 и 2, и так далее.

Если вы заглянете вовнутрь /sys/class/scsi_host/, вы обнаружите, что хосты от 0 до 6 соответствуют контроллерам SCSI.

Аналогично, в /sys/bus/scsi/devices/ присутствует структура в формате targetX:Y:Z и она подключается к своей шине SCSI:

Значения LUN могут идентифицироваться в рамках уникальной схемы четверной иерархии адресации, чтоб мы уже обсуждали ранее:

Теперь мы рассмотрим некоторые основные имеющие отношение к подсистеме SCSI структуры данных ядра.

 

Основные структуры данных

Все предыдущие понятия реализованы при помощи трёх основных структур данных - Scsi_Host, scsi_target и scsi_device. Естественно, это не единственные относящиеся ко SCSI структуры ядра. Дополнительно к этим трём имеются ряд вспомогательных структур, таких как scsi_host_template и scsi_transport_template. Как можно предположить из их названия, эти структуры применяются для представления неких общих функциональных возможностей адаптеров и типов транспорта SCSI. К примеру, scsi_host_template представляет общее содержимое хост- адаптеров одной и той же модели, включая глубину соответствующей очереди запросов, функцию обратного вызова обработки команд SCSI и функции восстановления обработки ошибок. Устройства SCSI включают в свой состав жёсткие диски, SSD, оптические приводы и тому подобное, а все эти устройства обладают некими общими функциями. Именно эти функции и выделены в шаблоны ядра.

Вот эти три основные структуры:

Такая иерархическая схема позволяет ядру действенно управлять устройствами SCSI и их взаимодействием. Передача команд и данных могут напрямую направляться в конкретные устройства или логические элементы SCSI, а обработка ошибок и отслеживание состояния могут осуществляться на каждом уровне иерархии. Всё взаимодействие этих структур обозначено на Рисунке 7.9.

Имейте в виду, что реальная реализация устройств SCSI в ядре Linux намного сложнее и вовлекает в себя дополнительные структуры данных и интерфейсы. Тем не менее, данная упрощённая схема демонстрирует базовое взаимодействие между структурами Хоста SCSI, Цели SCSI и Устройства SCSI.

 

Соединение с устройствами SCSI

Как это показано на Рисунке 7.10, существует три различных способа взаимодействия с устройствами SCSI:

 

Взаимодействие между SCSI и блочным уровнем

Уровень SCSI и блочный уровень работают сообща, облегчая взаимодействие между устройствами SCSI и файловой системой. Уровень SCSI действует в качестве промежуточного уровня между блочным уровнем и соответствующим драйвером устройства, специфичным для конкретного адаптера Хоста SCSI.

Ниже представлен некий обзор того, как уровень SCSI взаимодействует с блочным уровнем:

Пожалуйста, обратите внимание на то, что это обобщённый обзор взаимодействия между блочным уровнем и уровнем SCSI. Блочный уровень предоставляет стандартизированное взаимодействие с более верхними уровнями, например, для файловых систем. Уровень SCSI обрабатывает перевод запросов на ввод/ вывод блочного уровня в эквивалентные команды SCSI и управляет их взаимодействием с надлежащими устройствами SCSI через драйверы устройств более нижнего уровня, специфичные для конкретного адаптера Хоста SCSI.

Данная глава была сосредоточена на двух основных темах, а именно, на модели устройства и подсистеме SCSI в Linux. Мы начали с краткого обзора модели устройства Linux и того как ядро обеспечивает его представление в пространстве пользователя при через Sysfs VFS. Затем мы перешли к изучению подсистемы SCSI и пояснению её архитектуры из трёх уровней.

Как поясняла данная глава, SCSI определяет как интерфейс, так и протокол для соединения в системе устройств различного типа. В качестве среды, он определяет как устройства взаимодействуют друг с другом через шину SCSI. Когда приложение пространства пользователя инициирует запрос на запись для сохранения данных, подсистема SCSI преобразует этот запрос на запись в некую команду SCSI дабы выполнить запись данных запроса в конкретном местоположении диска. Он действует как посредник между своими более верхними уровнями общего стека ввода/ вывода и собственно физическим хранилищем. SCSI не берёт на себя ответственность за сборку блоков в процессе их транспорта или физического размещения на диске. Та сторона, которая инициирует запрос именуется инициатором, в то время как сторона назначения в терминологии SCSI носит название цели. Цель протокола SCSI способна охватывать отдельное физическое устройство, HBA или RAID контроллер. Первейшая обязанность протокола SCSI состоит в обеспечении успешного завершения полученной задачи записи и выдачи отчёта о её состоянии более верхнему уровню.

В свой следующей главе мы обсудим различные доступные в наши дни варианты физических хранилищ, такие как механические диски, SSD и устройства NVMe. Мы обсудим отличия в их архитектуре, а также рассмотрим как их сопоставлять друг с другом.