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

1.5.2 Вызов отложенной обработки

При запуске от процедуры обслуживания прерывания требуется быстрое и эффективное выполнение поставленной задачи. Таким образом, процедура обслуживания прерывания проводит минимум операций и размещает в очереди запрос на вызов отложенной обработки, который используется для завершения оставшихся операций с низким уровнем приоритета (эти уровни обычно называются IRQ или IRQL). Вызов отложенной обработки может быть размещен в очереди не только из процедуры обработки прерывания. Запрос к очереди создает новый объект вызова отложенной обработки (средствами диспетчера объектов). После размещения в очереди создается аппаратный запрос на прерывание (IRQ level 2) для вызова отложенной обработки.

Ниже описаны некоторые важные свойства вызова отложенной обработки.

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

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

Вызов отложенной обработки не должен выполнять блокирующие действия, например блокирующий ввод-вывод.

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

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

с высоким приоритетом размещается в начало очереди, a DPC с низким и средним приоритетом – в конец очереди.

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

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

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

Вызов отложенной обработки не может быть выгружен на диск.

1.5.3 Асинхронный вызов процедуры

Асинхронный вызов процедуры (asynchronous procedure call – АРС) немного похож на вызов отложенной обработки, но существуют и заметные различия. Как и вызов отложенной обработки, АРС выполняется на уровне привилегий, превышающем уровень привилегий обычного кода. В отличие от вызова отложенной обработки, выполняемого в контексте произвольного процесса, асинхронный вызов процедуры всегда выполняется в контексте определенного процесса. Таким образом, асинхронный вызов процедуры требует больших затрат, чем вызов отложенной обработки, так как приходится сохранять и восстанавливать большее количество параметров. Читателю, знакомому с операционными системами UNIX, асинхронные вызовы процедур напомнят процедуры обработки сигналов UNIX.

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

Код пользовательского режима тоже может использовать асинхронный вызов процедур. Для этого необходим прикладной интерфейс программирования QueueUserAPC, который рассматривается в документации к набору Platform SDK. Асинхронные вызовы процедур в пользовательском режиме предоставляются только тогда, когда поток получает предупреждение, например при блокировании в результате вызова функций WaitForSingleObject или WaitForMultipleObject. Подробная информация об этих функциях доступна в документации Platform SDK. Достаточно сказать, что эти функции позволяют организовать синхронизацию потоков.

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

1.6 Драйверы и буферы ввода-вывода

В этом разделе рассматриваются буферы ввода-вывода, которые уже упоминались ранее в главе. Драйверы используют буферы для осуществления ввода-вывода и управления им (IOCTL). Для этого драйверы посредством соответствующего объекта указывают предпочтительный способ ввода-вывода. Существует три поддерживаемых драйверами Windows NT типа ввода- вывода: буферизированный, прямой и небуферизированный. Эти методы рассматриваются в данном разделе.

1.6.1 Буферизированный ввод-вывод

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

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

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

1.6.2 Прямой ввод-вывод

Прямой ввод-вывод (Direct I/O) несколько более запутан, чем буферизированный, однако намного эффективнее при выполнении операций ввода- вывода для больших массивов данных. Диспетчер ввода-вывода выполняет базовые проверки, например проверяет разрешения приложения на доступ к буферу посредством области ввода-вывода желательного объема. Буфер в памяти, независимый от процесса, описывается для драйвера средствами структуры данных, которая называется список дескрипторов памяти (memory descriptor list – MDL). Адрес буфера используется в качестве общесистемного виртуального адресного пространства.

Операционная система Windows NT предоставляет процедуры драйверов, которые позволяют получать доступ к различным полям списка дескрипторов памяти. Создателям драйверов рекомендуется использовать список дескрипторов памяти в качестве целостного элемента. Дополнительная информация по использованию процедур работы со списками дескрипторов памяти приводится в документации к инструментарию создания драйверов (DDK) Windows NT. Процедуры, описанные в DDK, предоставляют следующие возможности:

• блокирование и разблокирование буфера приложения;

• связывание заблокированного буфера с виртуальным адресом, который доступен из контекста любого потока;

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

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

1.6.3 Небуферизированный ввод-вывод

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

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

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

Поскольку здесь затронута тема частного управления вводом-выводом, стоит упомянуть, что компания Microsoft настойчиво советует не применять такой способ управления, особенно при наличии более приемлемой альтернативы. Основная проблема частного управления вводом-выводом заключается в сложности проверки «жизнеспособности» кода драйвера методом намеренной передачи некорректных буферов процедуре управления вводом-выводом, что делается для проверки работоспособности драйвера. Для передачи некорректного буфера необходимо иметь информацию о правильном размере буфера, выравнивании и граничных условиях, которые предполагаются в коде управления вводом-выводом, а для частных операций управления вводом- выводом эти параметры каждый раз имеют другие значения.

1.7 Иерархия драйверов систем хранения и типы драйверов

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

В этом разделе представлен обзор стека драйверов устройств хранения Windows NT. Обратите внимание, что речь идет только о базовых, а не обо всех драйверах, связанных с подсистемой хранения данных. Например, драйверы, связанные со службами удаленного хранения (RSS), рассматриваются в главе 7.

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

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

При вводе-выводе данных посредством накопителя на магнитной ленте уровни управления томами и файловой системы не требуются.

В следующих подразделах рассматриваются драйверы шины, порта, класса, управления томами, файловой системы и фильтрации, представленные на рис. 1.5.

1.7.1 Драйверы шины

Драйвер шины Windows NT предоставляет функции шины другим драйверам. Термин шина используется в универсальном смысле, обозначая любое виртуальное или физическое устройство, к которому подключаются другие устройства. Драйверы шины необходимы для поддержки процедур перебора, которые вызываются диспетчером Plug and Play для перечисления устройств, подключенных к шине. Кроме того, от драйверов шины требуется предоставление кода обработки РпР, а также пакетов IRP для управления энергопитанием. Компания Microsoft предоставляет драйверы ввода-вывода для всех физических шин персональных компьютеров (например, SCSI, PCI, 1394, USB), хотя независимые поставщики оборудования также могут по мере необходимости предоставлять собственные драйверы шин. Драйвер шины создает объект физического устройства (physical device object – PDO) для каждого устройства, указанного процедурой перечисления устройств.

Рис. 1.5. Стек драйверов хранения Windows NT

1.7.2 Драйверы портов

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

В Windows NT предоставляются некоторые драйверы порта, включая SCSIPort и IEEE 1394. В свою очередь, Windows Server 2003 поставляется

с дополнительным драйвером порта, который называется Storport. На данный момент достаточно сказать, что драйвер SCSIPort используется для работы с устройствами SCSI-2 и более старыми устройствами, а драйвер Storport – с устройствами SCSI-3 и Fibre Channel. Дополнительная информация о драйвере Storport приводится в главе 2.

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

1.7.3 Драйверы классов

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

Создание объекта функционального устройства (FDO). Такой объект необходим для непосредственного использования устройства. В FDO могут содержаться такие данные, как структура организации диска (таблица разделов) или номер региона DVD.

Проверка действительности параметров IRP.

Повторная отправка запросов, обработка которых завершилась неудачно.

В частности, драйверы класса хранения данных выполняют описанные ниже операции.

Разбивка больших запросов чтения/записи (полученных с помощью IRP IRP_MJ_READ и IRP_MJ_WRITE) на меньшие множественные запросы, которые соответствуют возможностям физического адаптера шины.

Получение пакетов IRP и их трансляция в подходящие блоки запросов SCSI (SCSI request blocks – SRB), которые содержат встроенные блоки дескрипторов команд. После этого блоки запросов SCSI отправляются следующему драйверу в цепочке стека, который может оказаться драйвером фильтрации или драйвером порта. Блоки запросов SCSI при этом будут незавершенными, так как драйвер класса не заполняет информацию об адресации в блоке запроса SCSI и в этом зависит от драйвера более низкого уровня.

■ Участие в управлении питанием, добавление и удаление устройств, а также установка тайм-аута для ввода-вывода данных на устройства. Другими словами, драйверы класса устройств хранения активно принимают участие в реализации РпР и управлении энергопитанием.

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

К драйверам класса устройств хранения в Windows NT относятся, например, драйверы дисков, приводов компакт-дисков и накопителей на магнитной ленте; они могут работать с различными устройствами, в том числе подключенными к шинам SCSI, IDE, USB и 1394.

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

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

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

Интересно отметить, что Microsoft добавила в Windows 2000 новую библиотеку, которая называется ClassPnP. Эта библиотека реализует функциональные возможности РпР, общие для всех драйверов класса. При этом некоторые функции полностью реализуются драйвером класса. Для других функций драйвер, который использует библиотеку класса, должен предоставить процедуры обратного вызова, используемые драйвером класса при необходимости. Все драйверы класса, предоставляемые Microsoft (драйверы дисков, накопителей на магнитной ленте и драйверы приводов компакт-дисков), пользуются услугами библиотеки ClassPnP (она реализована в виде файла classpnp. sys). Та же ситуация сохранилась и в Windows XP/Windows Server 2003.

1.7.4 Дерево устройств Windows NT для устройств хранения данных

Описание различных уровней, показанных на рис. 1.5, все еще остается неполным. Однако немного отвлечемся перед обсуждением уровней управления томами и файловыми системами и рассмотрим дерево устройств, которое создается операционной системой. Знакомство с объектной моделью дерева устройств упрощает понимание тем, связанных с многопоточным вводом-выводом данных в отказоустойчивых устройствах хранения (см. главу 9) и с точками повторной обработки (см. главу 6). Поэтому имеет смысл рассмотреть данную тему сейчас, пока еще не забылась информация об объектах устройств, драйверах классов и портов, приведенная в предыдущих разделах.

Как уже отмечалось, технология РпР играет вареную роль в идентификации устройств. Интерфейс РпР загружает драйверы шины и инициирует обнаружение устройств, подключенных к этой шине. При обнаружении устройств РпР используется для загрузки соответствующих драйверов. В частности, перечисление устройств начинается с драйвера виртуальной (корневой) шины. Драйвер корневой шины отвечает за перечисление устаревших драйверов DOS и обычно используется для идентификации шин PCI. Драйверы, загруженные драйвером корневой шины, часто называют прошедшими корневое перечисление. К ним относится, например, драйвер шины МРIO (рассматривается в главе 9).

При загрузке драйверов и перечислении ими соответствующих устройств списки устройств передаются обратно интерфейсу РпР. При этом формируется дерево устройств, демонстрирующее схему их логического и физического взаимодействия. Обратите внимание, что РпР может только создать дерево; граф устройств не поддерживается. Таким образом, при использовании РпР дочерний узел может содержать только один родительский узел.

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

Рис. 1.6. Дерево драйверов устройств

На рис. 1.6 представлен подробный обзор лишь некоторых компонентов с рис. 1.5. В частности, на рис. 1.6 не показаны уровень управления томами и уровень файловых систем, в отличие от уровней драйверов классов и портов на рис. 1.5. Начиная с нижней правой области рис. 1.6, последовательность формирования дерева устройств выглядит так, как описано ниже.

Выполняемый модуль Windows NT (в частности, диспетчер РпР) создает объект физического устройства для драйвера шины PCI.

Драйвер шины PCI, в свою очередь, создает объект функционального устройства для шины PCI и подключает его к объекту физического устройства.

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

Диспетчер РпР загружает драйвер SCSIPort и после инициализации последнего вызывает его через входную точку входа AddDevice. При этом

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

Как уже отмечалось, драйвер может функционировать по-разному, и в данном случае драйвер SCSIPort действует в качестве драйвера шины, перечисляя устройства, которые подключены к шине SCSI. Драйвер обнаруживает диск и сообщает о нем диспетчеру РпР, который загружает драйвер класса диска (disk. sys). После инициализации драйвер класса диска вызывается через входную точку AddDevice и в качестве параметра получает объект физического устройства, который создается драйвером SCSI.