Наик Дайлип - Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003

• Название: Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003
• Автор: Наик Дайлип
• Издательство: Издательский дом «Вильямс»
• Жанр: Программное обеспечение
• Год: 2005
• ISBN: 5–8459–0746–2

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

---

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

Драйверы фильтрации существовали в 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.

1.8 Ввод-вывод типичного приложения хранения данных

Теперь соберем вместе все описываемые концепции и тщательным образом рассмотрим типичное приложение хранения данных. Это позволит разобраться с различными компонентами Windows NT, которые описывались ранее в главе, а также понять принципы их использования.

Рассматриваемое нами приложение будет просто считывать данные из файла. Файл размещен на томе, который управляется диспетчером томов FtDisk. Поскольку эта конфигурация идентична конфигурации, показанной на рис. 1.7, дерево объектов устройств не изменится. На рис. 1.8 представлена упрощенная версия дерева объектов устройств с рис. 1.7. Чтобы уменьшить объем предлагаемой информации, взаимодействие файловой системы с диспетчером кэша во внимание не принимается, т.е. предполагается, что файл не кэшируется.

Ниже описаны операции, которые приводятся на рис. 1.8.

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

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

Рис. 1.8. Операция чтения на томе

Диспетчер томов преобразует значение смещения тома в значение смещения на диске и заполняет соответствующий пакет IRP. Затем средствами диспетчера ввода-вывода пакет IRP отправляется драйверу класса диска.

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

Драйвер SCSIPort размещает пакет IRP в очереди, запрашивая некоторые операции у драйвера мини-порта, который управляет адаптером SCSI. На этом этапе пакет IRP отмечается как ожидающий выполнения и отправляется назад. Обычно диспетчер ввода-вывода обрабатывает пакет IRP в порядке, обратном только что описанному, т.е. после драйвера порта следует драйвер класса, затем диспетчер томов, а за ним файловая система. На каждом этапе пакет IRP отмечается как ожидающий выполнения. На определенном этапе ввод-вывод будет отправлен на физическое устройство средствами шины PCI.

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

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

Диспетчер ввода-вывода вызывает процедуру завершения драйвера класса диска. Процедура завершения выполняет необходимые операции обслуживания и вызывает диспетчер ввода-вывода для дальнейшей обработки пакета IRP. Диспетчер ввода-вывода переносит обработку на один уровень выше в цепочке стека драйверов. В данном случае к драйверу диспетчера томов FtDisk.

Вызывается процедура завершения драйвера FtDisk, которая выполняет собственную обработку. После завершения обработки вызывается диспетчер ввода-вывода, которому сообщается о завершении обработки пакета IRP. Диспетчер ввода-вывода переходит вверх по стеку и вызывает процедуру завершения следующего драйвера – драйвера файловой системы.

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

1.9 Сложности практической реализации

Стек ввода-вывода подсистемы хранения в семействе Windows Server описан в этой главе довольно подробно. Но помните, что стек подсистемы хранения не обслуживает устройства, поддерживающие несколько протоколов.

Чтобы повысить надежность и безопасность операционной системы Windows, компания Microsoft расширяет и улучшает методику сертификации и подписи драйверов. Поставщикам рекомендуется сертифицировать все обновления драйверов. Хорошим источником информации по этому вопросу может служить Web-узел компании Microsoft, в частности Web-страница по адресу: http://www.microsoft.com/hwdev/driver/drvsign. asp.

Резюме

Операционная система Windows NT проектировалась в качестве многоуровневой и расширяемой, особенно в контексте подсистем хранения и ввода-вывода данных. Создание драйвера соответствующего типа (например, драйвера мини-порта SCSIPort или мини-драйвера Storport) позволяет без проблем добавить поддержку нового устройства.