Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003
Шрифт:
Драйверы файловой системы представляют собой драйверы устройств Windows NT, которые реализуют возможности файловой системы. Хотя файловая система содержится на физическом носителе, например на компакт- диске или жестком диске, драйверы файловой системы рассматриваются в качестве логических, поскольку не используются для непосредственного управления аппаратным обеспечением. Драйверы файловых систем полагаются на драйверы портов и классов для обеспечения ввода-вывода данных на диск и с него. Драйвер
Заполняет следующий фрагмент стека пакета IRP необходимой информацией для завершения ввода-вывода. После этого пакет IRP отправляется драйверу класса.
Создает последовательность пакетов IRP для выполнения запрошенного ввода-вывода.
Драйвер файловой системы содержит метаданные на самом носителе. В метаданные входит информация о разрешениях доступа к файловой системе и таблица размещения файлов (расположение файлов на диске). Драйвер файловой системы получает пакет IRP, который указывает на определенную операцию по отношению к файлу, считывает необходимые метаданные и отправляет запрос IRP, который уже относится к блоку диска, а не к файлу. Операционная система поставляется с драйверами файловых систем NTFS, UDFS и FAT.
Создание драйвера файловой системы или драйверов фильтрации для файловых систем в Windows NT З. х; поначалу считали «черной магией». Впоследствии Microsoft предоставила инсталляционный инструментарий файловых систем (Installable File System Kit), который содержит необходимые заголовочные файлы, документацию и примеры создания файловых систем и драйверов фильтрации файловых систем.
Драйверы как файловых систем, так и фильтрации файловых систем должны обеспечивать поддержку пакетов IRP РпР, включая управление питанием, удаление носителя и самого устройства хранения (например, внешнего дисковода на гибких дисках, подключаемого к шине USB).
Драйверы фильтрации размещены выше других объектов устройств в иерархической структуре драйверов и выполняет предварительную и/или последующую обработку запросов ввода-вывода для модификации работы системы. Драйверы фильтрации обычно используются для выполнения перечисленных ниже задач.
Поддержка модульной структуры, например посредством драйвера фильтрации музыкальных компакт-дисков.
Добавление функциональных возможностей, например записи компакт- дисков на соответствующих устройствах.
Добавление функциональных возможностей файловой системе, например драйверов фильтрации для шифрования, точек повторной обработки и SIS – Single Instance Storage (рассматривается в главе 6).
Добавление функций шины. Например, в виде поддержки шины AGP или расширений ACPI BIOS.
Изменение процесса ввода-вывода для того, чтобы он соответствовал особенностям функционирования аппаратного обеспечения, например разбивка пакетов ввода-вывода на меньшие фрагменты.
Драйверы фильтрации всегда создают объект устройства, который подключен к объекту функционального устройства или к объекту физического устройства (эти объекты рассматриваются в разделе 1.4.2). Объект устройства необходим драйверу фильтрации для получения пакетов IRP и выполнения предварительной и/или последующей обработки запросов ввода-вывода.
Некоторые драйверы фильтрации создают вторичный объект устройства, который часто называется объектом управляющего устройства (control device object – CDO), так как он используется
Драйверы фильтрации нижнего уровня отличаются более сложной структурой, чем драйверы верхнего уровня. К одной из технических проблем относится выбор сообщаемых ошибок,, а также операций ввода-вывода, ошибки которых сообщаются. Еще одна проблема – отсутствие готовых примеров драйверов нижнего уровня, поскольку все доступные примеры описывают драйверы верхнего уровня. Иногда (достаточно редко) драйверы нижнего уровня предоставляют функции протокольного преобразователя или функции, позволяющие обойти некоторые ограничения в работе аппаратного устройства.
Драйверы фильтрации существовали в Windows NT с момента появления ее первой коммерческой версии. Пакет Windows NT Installable File System Kit (http://www.microsoft.com/ddk/IFSKit) представляет собой неплохой справочник для разработчиков, в котором подробно документируется архитектура драйверов фильтрации.
Начиная с Windows 2000, в процесс загрузки драйверов фильтрации были внесены значительные изменения. Ранее дополнительная работа по проверке правильности загрузки драйвера ложилась на плечи создателя драйвера. Если драйвер загружался слишком рано, объект устройства, к которому должен подключиться драйвер, мог еще не существовать. Если драйвер загружался слишком поздно, устройство могло оказаться занятым другим драйвером; это приводило к тому, что драйвер фильтрации в стеке драйверов помещался выше, чем было необходимо. В Windows 2000 создатель драйвера указывает размещение драйвера выше или ниже определенного объекта физического устройства или объекта функционального устройства, а диспетчер Plug and Play загружает драйвер в подходящее время.
Похоже* что компания Microsoft чересчур упростила процесс создания драйвера фильтрации. Цепь стека драйверов стала чрезмерно «переполненной», что подразумевает проблемы с производительностью и загрузкой памяти (каждый пакет IRP должен содержать больше фрагментов стека, а пакеты IRP размещаются в невыгружаемой памяти). Достаточно посмотреть на список драйверов фильтрации, которые загружаются в операционной системе:
драйвер фильтрации шифрованной файловой системы;
драйвер фильтрации, используемый для управления иерархическим хранением и для служб удаленного хранения;
драйвер фильтрации SIS для служб удаленной установки (RIS);
драйверы фильтрации для точек повторной обработки от сторонних поставщиков;
драйверы фильтрации для антивирусного программного обеспечения.
С другой стороны, создание драйвера фильтрации бывает достаточно сложным. Представьте себе драйвер, который должен выполнять шифрование данных при записи на диск и дешифрацию при считывании. Все, что на самом деле необходимо драйверу, это доступ к буферам до их записи и после считывания. Но создатель драйвера не имеет возможности просто зарегистрировать функцию обратного вызова для быстрого выполнения необходимой функции и вынужден сталкиваться с различными трудностями, в частности с обработкой отмененных пакетов IRP.