Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003

1.3.4.3 Драйверы файловых систем

Операционная система предоставляет функции файловых систем с помощью драйверов режима ядра. Система Windows NT поставляется вместе с такими файловыми системами:

NTFS (файловая система NT);

UDFS (универсальная дисковая файловая система);

CDFS (файловая система компакт-дисков);

FAT (таблица размещения файлов).

Драйверы сетевых файловых систем рассматриваются в главе 3. Драйверы файловых систем реализуются средствами инструментария разработки драйверов Windows NT (Windows NT DDK) и дополнительного программного продукта, который предлагается компанией Microsoft – Windows NT Installable File System Kit. Этот инструментарий содержит документацию для различных программных интерфейсов приложений, которые понадобятся при создании драйверов файловой системы, а также пример кода, предназначенного для реализации файловых систем FAT и UDFS.

Драйверы файловой системы аналогичны другим драйверам, поскольку взаимодействуют с диспетчером ввода-вывода и IRP. Драйверы файловой системы являются логическими, так как не взаимодействуют непосредственно с аппаратным обеспечением; например, файловая система не делает различия между дисками с интерфейсом SCSI и с интерфейсом АТА (иногда называемым IDE). Тем не менее драйверы файловой системы отличаются от других драйверов. Некоторые из этих отличий приведены ниже.

Драйверы файловой системы всегда вызываются в контексте потока, запрашивающего операцию ввода-вывода.

Драйверы файловой системы активно взаимодействуют с диспетчером кэша и диспетчером виртуальной памяти, используя эти два компонента для буферизации данных. Например, файловая система использует услуги диспетчера кэша для кэширования метаданных файловой системы (это может быть расположение файлов и каталогов на диске), чтобы избежать повторных запросов одних и тех же метаданных.

Драйверы файловой системы являются единственными драйверами, которые обеспечивают работу методов ввода-вывода на основе IRP. Подобный метод называется быстрым вводом-выводом (Fast I/O) и представляет собой несколько входных точек драйвера. Диспетчер ввода-вывода вызывает эти точки для выполнения операций ввода-вывода, поскольку данные могут быть кэшированы и поэтому быстро обработаны. Драйвер файловой системы может завершить вызов неудачно, если это необходимо, а диспетчер ввода-вывода просто повторит тот же запрос ввода- вывода с помощью обычного пакета IRP.

Понятие драйверов фильтров файловых систем тесно связано с понятием драйверов файловых систем. Драйверы фильтрации файловых систем используются для реализации широкого диапазона различных технологий, например шифрованной файловой системы (EFS) и поддержки служб удаленного хранения (RSS).

1.3.4.4 Графическая подсистема

Поскольку эта книга посвящена корпоративным системам хранения данных, на рис. 1.2 графическая подсистема демонстрируется в режиме ядра, хотя некоторая область подсистемы также представлена и в пользовательском режиме. В Windows 2000 для повышения производительности значительный объем кода графической подсистемы был перемещен из пользовательского режима в режим ядра. В данном случае к понятию «графическая подсистема» относится весь программный код, предназначенный для обработки оконного интерфейса и поддерживающий видеоустройства, сканеры, принтеры и т.д.

1.3.4.5 Подсистема Win32

Это наиболее важный компонент Windows NT, особенно для программистов. На основе программного интерфейса Win32 создаются другие подсистемы, такие, как POSIX.

Программный интерфейс приложений Win32 можно разделить на три категории.

1. Обработка оконного интерфейса и API для сообщений оконного интерфейса реализованы в виде динамически подключаемой библиотеки user32. dll. Эта библиотека подключается приложениями, использующими интерфейсы, которые предоставляются этим файлом. При этом несколько приложений во время работы задействуют только одну копию библиотеки.

2. Графический API реализован в виде динамически подключаемой библиотеки gdi32. dll. В версиях Windows NT до Windows 2000 библиотека gdi32. dll являлась клиентом, подключаемым к серверному процессу Win32 (рассматривается далее), так как соответствующие функции были реализованы в серверном процессе. А сервер Win32, в свою очередь, вызывал компонент режима ядра для графической подсистемы. В Windows 2000 библиотека gdi32. dll вызывает этот компонент без посредников.

3. Базовые API, например функции открытия файла (CreateFile), чтения файла (ReadFile) и записи файла (WriteFile), реализованы в динамически подключаемой библиотеке, которая называется ntdll.dll. При необходимости эта библиотека делает вызовы к выполняемому модулю Windows в режиме ядра. Для этого библиотека использует одно из 256 прерываний, поддерживаемых архитектурой Intel х86. В частности, используется прерывание 46 (десятичный номер 46, шестнадцатеричный – 0х2Е). Обработчик прерывания[2] идентифицирует как запрошенный API (выполнив поиск по таблице), так и передаваемые ему параметры. Если все параметры прошли проверку, обработчик вызывает соответствующую подсистему выполняемого модуля Windows для выполнения запрошенной операции.

Приложения, написанные на основе API Win32 и других механизмов поддержки, рассматриваются в документации SDK. В некотором смысле даже подсистема POSIX представляет собой инструмент, разработанный для поддержки приложений UNIX. Хотя подсистема POSIX в настоящий момент существенной роли уже не играет, она все еще служит хорошим примером модульной и расширяемой архитектуры Windows NT.

1.4 Структуры данных, связанные с драйверами устройств Windows

Перед подробным рассмотрением драйверов устройств Windows NT стоит разобраться в некоторых важных структурах данных, которые используются этими драйверами. Каждый драйвер Windows, включая драйверы устройств хранения данных, должен взаимодействовать с тремя основными типами объектов: объектами драйверов, объектами устройств и пакетами запроса ввода- вывода (IRP). Эти объекты и рассматриваются в данном разделе.

1.4.1 Объекты драйверов

Объект драйвера создается выполняемым модулем Windows NT при загрузке драйвера. Объект драйвера выделяется из невыгружаемой памяти. Он содержит важную информацию, например таблицу вызовов драйвера, которая, в свою очередь, содержит адреса для различных процедур драйвера. Каждый драйвер, даже если он управляет несколькими устройствами, представлен только одним объектом. Кроме того, когда драйвер обрабатывается несколькими ЦПУ в многопроцессорной системе Windows NT, в памяти присутствует только один объект драйвера. Хотя объект драйвера создается выполняемым модулем Windows NT, обязанность по внесению определенной информации, например адресов процедур в таблицу вызовов драйвера, возлагается на создателя драйвера. Это требование относится только к драйверам, которые экспортируют объект драйвера; таким образом, мини-драйверы, которые зависят от классов или портов объекта драйвера, не обязаны предоставлять описываемую информацию об объекте.

1.4.2 Объекты устройств

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

Три типа объектов устройства имеют одинаковую структуру, однако различаются расширениями и методами использования. Эти объекты описаны ниже.

Объект физического устройства (physical device object – PDO) представляет собой устройство, подключенное к шине и обычно создается драйвером шины (драйверы шины рассматриваются в разделе 1.7.1). Объект физического устройства должен поддерживать связь с устройством. Такой объект должен хранить статус энергопитания устройства и идентификатор устройства, например идентификатор шины SCSI, целевой идентификатор SCSI и номер логической единицы (LUN) SCSI. Эти термины более подробно рассматриваются в главе 2. На данный момент достаточно сказать, что для уникальной идентификации устройства SCSI необходимо указать три значения: идентификатор шины, целевой идентификатор и идентификатор LUN.

Объект функционального устройства (functional device object – FDO) обычно создается драйвером класса или драйвером порта (драйверы классов и портов рассматриваются в разделах 1.7.2 и 1.7.3). Использование устройства требует наличия объекта функционального устройства. В качестве примера данных, которые содержатся в объекте функционального устройства, можно указать элементы архитектуры диска, например таблицу разделов диска или в контексте привода DVD информацию о регионе DVD.

Рис. 1.3. Архитектура объекта устройства Windows NT

3. Объект фильтра устройства (filter device object – DO) представляет собой устройство для драйвера фильтра.

На рис. 1.3 демонстрируются основные структурные элементы объекта драйвера.

К важным элементам объекта драйвера относится таблица вызовов. В ней определены различные стандартные функции, которые реализуются драйвером устройства. В зависимости от конкретной структуры драйвера, некоторые из этих функций должны быть реализованы в обязательном, а некоторые – в произвольном порядке. На рис. 1.3 показаны только функции Read, Write и DeviceIoControl, однако существует и множество других. Для получения дополнительной информации можно обратиться к инструментарию разработки драйверов Windows.

Устройства, функции которых реализуются с помощью драйвера, описываются посредством объектов устройств (PDO, FDO и DO). Все устройства представлены в связном списке. Заголовок связного списка хранится в объек-

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

1.4.3 Пакеты запросов ввода-вывода

Для взаимодействия с драйверами режима ядра многоуровневая операционная система Windows NT использует интерфейсы на основе пакетов данных. Пакеты, которые используются для связи с драйверами, называются пакетами запроса ввода-вывода (I/O request packets – IRP). К драйверу может подключаться другой драйвер или подсистема ввода-вывода.

Пакеты IRP выделяются в невыгружаемой памяти – важнейшем системном ресурсе. Пакеты запроса ввода-вывода выделяются и поддерживаются в очереди, связанной с определенным потоком. Операционная система Windows NT поддерживает готовность к работе некоторого количества пакетов IRP, размещенных в выделенном[3] списке, что позволяет после запроса быстро назначать пакеты драйверу или диспетчеру ввода-вывода.

На рис. 1.4 показано, что пакет запроса ввода-вывода имеет заголовок фиксированного размера и непостоянное количество элементов стека ввода- вывода. Элементы стека ввода-вывода представляют структуры данных для отдельных драйверов, которые будут обрабатывать IRP. Таким образом, каждый драйвер, который обрабатывает пакет запроса ввода-вывода, получает закрытую область данных в стеке пакета. При выделении и отправке пакета драйверу требуется формирование стека достаточного объема для каждого драйвера, который будет обрабатывать пакет. Если драйвер попытается получить доступ к несуществующему элементу стека IRP, это может привести к появлению ошибок в работе системы. Таким образом, пакет запроса ввода- вывода, который может использоваться для одной цепи стека драйвера, не всегда подходит для другой цепи этого стека.

На рис. 1.4 демонстрируется, что заголовок пакета запроса ввода-вывода содержит различные поля данных, перечисленные ниже.

Тип запроса (синхронный или асинхронный).

Тип операции запроса (операция страничного ввода-вывода или операция, выполняемая без промежуточного кэширования).

Указатель на буфер для операции ввода-вывода.

Рис. 1.4. Структура пакета запроса ввода-вывода

Статус блока ввода-вывода, который представляет состояние пакета запроса ввода-вывода. Этот статус меняется при обработке пакета различными драйверами.

Информация, необходимая для обработки отмены IRP в случае отмены операции ввода-вывода, указанной в пакете (например, после достижения тайм-аута или по команде пользователя, который решил, что операция выполняется слишком долго).

Указание области возникновения запроса ввода-вывода (в пользовательском режиме или режиме ядра).

Кроме того, на рис. 1.4 показано, что каждый элемент стека содержит информацию, относящуюся к конкретному драйверу. Ниже приведено несколько примеров информации, которая содержится в элементе стека.

Код основной функции (чтение, запись и операция по управлению устройством).

Код вторичной функции, который уточняет необходимое действие и применяется только вместе с соответствующим кодом основной функции.

Параметры функции, например параметры управления устройством.

Указатель на объект файла.

Структура пакета запроса ввода-вывода содержит элемент, указывающий на текущий элемент» стека пакета. Драйвер отвечает за изменение значения этого элемента перед передачей пакета следующему драйверу в цепочке драйверов. Каждый активный пакет запроса ввода-вывода размещается в очереди, связанной с потоком, который содержит пакеты запроса ввода-вывода, связанные с вводом-выводом, запрошенным этим потоком.

В ответ на полученные пакеты драйвер может создавать вторичные пакеты IRP, которые могут обрабатываться одновременно, имитируя параллельную обработку. Это позволяет ускорить обработку ввода-вывода данных. Конечно, в этом случае существуют определенные ограничения: например, операция записи на ленту не может быть разделена на несколько параллельных операций.

1.5 Структура драйвера устройства Windows

Все драйверы устройств Windows имеют одинаковую структуру. Каждый драйвер имеет объект драйвера, который создается диспетчером ввода-вывода при загрузке драйвера. В разделе 1.4 представлены структуры данных, которые относятся к драйверам устройств, в том числе и объекты драйверов. В этом разделе описываются процедуры, реализуемые драйвером, а также другие характеристики драйвера устройства хранения данных.

Драйвер устройства Windows реализует множество стандартных процедур, причем некоторые из них обязательны для выполнения, а некоторые – нет, что зависит от свойств драйвера. Ниже перечислены основные стандартные процедуры.

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

• Обязательный набор процедур диспетчеризации для обеспечения работы определенных функций, например чтения, записи, создания и закрытия файлов. Эти процедуры вызываются диспетчером ввода-вывода и получают в качестве параметра пакет запроса ввода-вывода.

• Необязательная процедура запуска (startup routine – StartIO), которая инициирует ввод-вывод данных на физическое устройство. Очевидно, что только драйверы, работающие непосредственно с физическими устройствами (это касается не всех драйверов такого типа), требуют наличия такой процедуры.

• Необязательная процедура обслуживания прерывания (interrupt service routine – ISR). Может использоваться драйверами, взаимодействующими с физическими устройствами. Процедуры обслуживания прерываний рассматриваются в разделе 1.5.1.

• Необязательный отложенный вызов процедуры' (deferred procedure call – DPC), который может использоваться драйвером для дополнительной обработки процедуры обслуживания прерывания. Отложенный вызов процедуры рассматривается в разделе 1.5.2.

• Необязательная процедура завершения, которая вызывается диспетчером ввода-вывода (в качестве механизма уведомления), когда драйвер более низкого уровня завершает обработку пакета запроса ввода-вывода. Поскольку вся операция ввода-вывода обрабатывается в качестве асинхронной, процедура завершения используется довольно часто, особенно в высокоуровневых драйверах, которые всегда обеспечивают обработку пакетов IRP более низкого уровня.

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

• Необязательная процедура отмены (cancellation routine – CancellO), которая вызывается диспетчером ввода-вывода для отмены выполнения длительной операции.

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

• Необязательная процедура протоколирования ошибок.

Обработка пакета запроса ввода-вывода совершается драйвером различными способами, в зависимости от структуры драйвера и запроса ввода-вы- вода в пакете. Ниже приведены некоторые примеры работы драйвера.

• Выполнение запрошенной операции и завершение обработки IRP.

• Выполнение элемента операции и передача IRP драйверу более низкого уровня.

• Обычная передача IRP драйверу более низкого уровня.

• Генерация нескольких пакетов IRP для драйвера более низкого уровня в ответ на получение одного пакета IRP. Например, в ответ на запрос об открытии файла, поступивший от драйвера NTFS, драйверу может потребоваться считать метаданные файла для поиска каталога и подкаталогов, в которых расположен необходимый файл.

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

Обратите внимание, что один и тот же код драйвера может одновременно выполняться на разных центральных процессорах в одной системе Windows NT. Код драйвера должен обладать возможностью синхронизировать доступ к критическим данным кода, выполняемого на разных процессорах. Иногда повторное выполнение одного запроса может стать просто катастрофой, например при записи на магнитную ленту одних и тех же данных повторно.

1.5.1 Процедура обслуживания прерывания

Процедура обслуживания прерывания (interrupt service routine – ISR) обычно выполняется в ответ на получение прерывания от аппаратного устройства и может вытеснять любой код с более низким приоритетом. Процедура обслуживания прерывания должна использовать минимальное количество операций, чтобы центральный процессор имел свободные ресурсы для обслуживания других прерываний. Эта процедура собирает минимум необходимой информации и размещает в очереди вызов отложенной обработки (deffered processing call – DPC) для завершения обслуживания прерывания. Запуск вызова отложенной обработки не планируется на определенное время, т.е. вызов может быть запущен как немедленно, так и немного позднее, в зависимости от необходимости в другой обработке.

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

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