Похоже* что компания Microsoft чересчур упростила процесс создания драйвера фильтрации. Цепь стека драйверов стала чрезмерно «переполненной», что подразумевает проблемы с производительностью и загрузкой памяти (каждый пакет IRP должен содержать больше фрагментов стека, а пакеты IRP размещаются в невыгружаемой памяти). Достаточно посмотреть на список драйверов фильтрации, которые загружаются в операционной системе:
драйвер фильтрации шифрованной файловой системы;
драйвер фильтрации, используемый для управления иерархическим хранением и для служб удаленного хранения;
драйвер фильтрации SIS для служб удаленной установки (RIS);
драйверы фильтрации для точек повторной обработки от сторонних поставщиков;
драйверы фильтрации для антивирусного программного обеспечения.
С другой стороны, создание драйвера фильтрации бывает достаточно сложным. Представьте себе драйвер, который должен выполнять шифрование данных при записи на диск и дешифрацию при считывании. Все, что на самом деле необходимо драйверу, это доступ к буферам до их записи и после считывания. Но создатель драйвера не имеет возможности просто зарегистрировать функцию обратного вызова для быстрого выполнения необходимой функции и вынужден сталкиваться с различными трудностями, в частности с обработкой отмененных пакетов IRP.
1.8 Ввод-вывод типичного приложения хранения данных
Теперь соберем вместе все описываемые концепции и тщательным образом рассмотрим типичное приложение хранения данных. Это позволит разобраться с различными компонентами Windows NT, которые описывались ранее в главе, а также понять принципы их использования.
Рассматриваемое нами приложение будет просто считывать данные из файла. Файл размещен на томе, который управляется диспетчером томов FtDisk. Поскольку эта конфигурация идентична конфигурации, показанной на рис. 1.7, дерево объектов устройств не изменится. На рис. 1.8 представлена упрощенная версия дерева объектов устройств с рис. 1.7. Чтобы уменьшить объем предлагаемой информации, взаимодействие файловой системы с диспетчером кэша во внимание не принимается, т.е. предполагается, что файл не кэшируется.
Ниже описаны операции, которые приводятся на рис. 1.8.
Приложение, например резервного копирования, выдает запрос на чтение. 'После ряда стандартных проверок подсистема ввода-вывода перенаправляет запрос с помощью пакета IRP соответствующей файловой системе.
Файловая система определяет, что ей необходимо получить данные тома. Драйвер файловой системы создает пакет IRP с необходимыми параметрами, включая смещение в пределах тома, где должна быть выполнена операция чтения, и объем операции чтения. Кроме того, драйвер файловой системы указывает процедуру завершения ввода-вывода. После этого драйвер файловой системы отправляет пакет IRP диспетчеру томов.
Рис. 1.8. Операция чтения на томе
Диспетчер томов преобразует значение смещения тома в значение смещения на диске и заполняет соответствующий пакет IRP. Затем средствами диспетчера ввода-вывода пакет IRP отправляется драйверу класса диска.
После получения пакета IRP драйвер класса диска заполняет процедуру завершения в собственном элементе стека в пакете IRP. Обычно драйвер класса диска создает еще один пакет IRP (он называется
Драйвер SCSIPort размещает пакет IRP в очереди, запрашивая некоторые операции у драйвера мини-порта, который управляет адаптером SCSI. На этом этапе пакет IRP отмечается как ожидающий выполнения и отправляется назад. Обычно диспетчер ввода-вывода обрабатывает пакет IRP в порядке, обратном только что описанному, т.е. после драйвера порта следует драйвер класса, затем диспетчер томов, а за ним файловая система. На каждом этапе пакет IRP отмечается как ожидающий выполнения. На определенном этапе ввод-вывод будет отправлен на физическое устройство средствами шины PCI.
В какой-то момент ввод-вывод будет завершен. Чтобы упростить описание, предположим, что операция ввода-вывода завершилась без ошибок. По завершении операции ввода-вывода генерируется программное прерывание.