Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003
Шрифт:
Драйверы файловой системы активно взаимодействуют с диспетчером кэша и диспетчером виртуальной памяти, используя эти два компонента для буферизации данных. Например, файловая система использует услуги диспетчера кэша для кэширования метаданных файловой системы (это может быть расположение файлов и каталогов на диске), чтобы избежать повторных запросов одних и тех же метаданных.
Драйверы файловой системы являются единственными драйверами, которые обеспечивают работу методов ввода-вывода на основе IRP. Подобный метод называется быстрым вводом-выводом (Fast I/O) и представляет собой несколько входных точек драйвера. Диспетчер ввода-вывода вызывает эти точки для выполнения операций ввода-вывода, поскольку данные могут быть кэшированы и поэтому быстро обработаны. Драйвер файловой системы может завершить вызов неудачно, если это необходимо, а диспетчер ввода-вывода просто повторит
Понятие драйверов фильтров файловых систем тесно связано с понятием драйверов файловых систем. Драйверы фильтрации файловых систем используются для реализации широкого диапазона различных технологий, например шифрованной файловой системы (EFS) и поддержки служб удаленного хранения (RSS).
Поскольку эта книга посвящена корпоративным системам хранения данных, на рис. 1.2 графическая подсистема демонстрируется в режиме ядра, хотя некоторая область подсистемы также представлена и в пользовательском режиме. В Windows 2000 для повышения производительности значительный объем кода графической подсистемы был перемещен из пользовательского режима в режим ядра. В данном случае к понятию «графическая подсистема» относится весь программный код, предназначенный для обработки оконного интерфейса и поддерживающий видеоустройства, сканеры, принтеры и т.д.
Это наиболее важный компонент 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 для выполнения запрошенной операции.
2
Строго говоря, это не просто обработчик прерываний, однако в данный момент не будем углубляться в детали, поэтому далее обработчик прерываний будет именоваться просто прерыванием.
Приложения, написанные на основе API Win32 и других механизмов поддержки, рассматриваются в документации SDK. В некотором смысле даже подсистема POSIX представляет собой инструмент, разработанный для поддержки приложений UNIX. Хотя подсистема POSIX в настоящий момент существенной роли уже не играет, она все еще служит хорошим примером модульной и расширяемой архитектуры Windows NT.
1.4 Структуры данных, связанные с драйверами устройств Windows
Перед подробным рассмотрением драйверов устройств Windows NT стоит разобраться в некоторых важных структурах данных, которые используются этими драйверами. Каждый драйвер Windows, включая драйверы устройств хранения данных, должен взаимодействовать с тремя основными типами объектов: объектами драйверов, объектами устройств и пакетами запроса ввода- вывода (IRP). Эти объекты и рассматриваются в данном разделе.
Объект драйвера создается выполняемым модулем Windows NT при загрузке драйвера. Объект драйвера выделяется из невыгружаемой памяти. Он содержит важную информацию, например таблицу вызовов драйвера, которая, в свою очередь, содержит адреса для различных процедур драйвера. Каждый драйвер, даже если он управляет несколькими устройствами, представлен только одним объектом. Кроме того, когда драйвер обрабатывается несколькими ЦПУ в многопроцессорной системе Windows NT, в памяти присутствует только один объект драйвера. Хотя объект драйвера создается выполняемым модулем Windows NT, обязанность по внесению определенной информации, например адресов процедур в таблицу вызовов драйвера, возлагается на создателя драйвера. Это требование относится только к драйверам, которые экспортируют объект драйвера; таким образом, мини-драйверы, которые зависят от классов или портов объекта драйвера, не обязаны предоставлять описываемую информацию об объекте.
Объект устройства представляет собой физическое устройство ввода- вывода (т.е. шинный адаптер, диск или привод на магнитных лентах) или логическое устройство (например, драйвер антивирусного фильтра). Каждое устройство может быть представлено только одним объектом устройства. Объект устройства содержит указатель на объект драйвера, который управляет обработкой устройства. Кроме того, объект устройства описывает физические характеристики устройства, например наибольший объем ввода- вывода данных, выполняемый за одну операцию, или компонент, посредством которого выравнивается буфер, предоставляемый устройству.
Три типа объектов устройства имеют одинаковую структуру, однако различаются расширениями и методами использования. Эти объекты описаны ниже.
Объект физического устройства (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.