"3.Внутреннее устройство Windows (гл. 8-11)" - читать интересную книгу автора (Руссинович Марк, Соломон Дэвид)

ГЛABA 10  Управление внешней памятью

Термин внешняя память (storage) относится к носителям, применяемым в самых разнообразных устройствах, в том числе к магнитным лентам, оптическим дискам, гибким дискам, локальным жестким дискам и сети устройств хранения данных (storage area networks, SAN). Windows предоставляет специализированную поддержку для каждого класса носителей внешней памяти. Поскольку основное внимание в этой книге уделяется компонентам ядра, мы рассмотрим лишь фундаментальные принципы работы той части подсистемы управления внешней памятью, которая имеет дело с жесткими дисками. Существенную часть поддержки сменных носителей и удаленных устройств внешней памяти Windows реализует в пользовательском режиме.

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

Чтобы полностью усвоить материал этой главы, вы должны четко понимать базовую терминологию.

• Диск — физическое устройство внешней памяти, например жесткий диск, 3,5-дюймовая дискета или компакт-диск (CD-ROM).

• Диск делится на секторы, блоки фиксированного размера. Размер сектора определяется аппаратно. Например, размер сектора жесткого диска, как правило, составляет 512 байтов, а размер сектора CD-ROM — обычно 2048 байт.

• Раздел (partition) — набор непрерывных секторов на диске. Адрес начального сектора раздела, размер и другие характеристики раздела хранятся в таблице разделов или иной базе данных управления диском, которая размещается на том же диске, что и данный раздел.

• Простой том (simple volume) — объект, представляющий секторы одного раздела, которым драйверы файловых систем управляют как единым целым.

• Составной том (multipartition volume) — объект, представляющий секторы нескольких разделов, которыми драйверы файловых систем управляют как единым целым. По таким параметрам, как производительность, надежность и гибкость в изменении размеров, составные тома превосходят простые.

Драйверы устройств, участвующие в управлении конкретным устройством внешней памяти (накопителем), обобщенно называются стеком драйверов внешней памяти (storage stack). Ha рис. 10-1 показаны все типы драйверов, которые могут присутствовать в стеке. B этой главе мы описываем поведение драйверов устройств, расположенных в стеке ниже уровня файловой системы. (O драйвере файловой системы см. главу 12.)

Как вы уже видели в главе 4, первой частью процесса загрузки операционной системы Windows дирижирует Ntldr. Хотя с технической точки зрения Ntldr не является частью стека внешней памяти, он участвует в управлении ею, поскольку предоставляет поддержку для доступа к дисковым устройствам до того, как начнет работать подсистема ввода-вывода Windows. Он находится на системном томе и запускается кодом, размещенным в загрузочном секторе этого тома. Ntldr считывает с системного тома файл Boot.ini и предлагает пользователю выбрать вариант загрузки. Имена разделов в Boot.ini представлены в виде multi(0)disk(0)rdisk(0)partition(l). Эти имена являются частью стандартной схемы именования разделов Advanced RISC Computing (ARC), используемой микрокодом Alpha и других RISC-процессоров. Ntldr транслирует имя выбранного пользователем элемента Boot.ini в имя загрузочного раздела и загружает в память системные файлы Windows (начиная с реестра, Ntoskrnl.exe и загрузочных драйверов). Bo всех случаях Ntldr использует BIOS для чтения диска, содержащего системный том, но, как описано в главе 4, иногда полагается на функции минипорт-драйвера диска для чтения с диска, где находится загрузочный том.

При инициализации диспетчер ввода-вывода запускает драйверы жестких дисков. Драйверы устройств внешней памяти в Windows соответствуют архитектуре «класс-порт-минипорт». Согласно этой архитектуре, Microsoft предоставляет драйвер класса внешней памяти, который реализует функциональность, общую для всех устройств внешней памяти, и порт-драйвер, который поддерживает функциональность, общую для конкретной шины, например SCSI (Small Computer System Interface) или IDE (Integrated Device Electronics). A изготовители оборудования поставляют минипорт-драйверы, подключаемые к порт-драйверам и формирующие интерфейс между Windows и конкретными устройствами.

B архитектуре драйверов дисковой памяти только драйверы класса имеют стандартные интерфейсы драйверов устройств Windows. Минипорт-драйверы вместо интерфейса драйверов устройств используют интерфейс порт-драйверов, который просто реализует набор процедур, служащих интерфейсом между Windows и минипорт-драйверами. Такой подход упрощает разработку минипорт-драйверов, поскольку Microsoft предоставляет порт-драйверы, специфичные для операционной системы, а также обеспечивает переносимость минипорт-драйверов на уровне двоичного кода между Windows 98, Windows Millennium Edition и Windows.

Windows включает драйвер класса дисков (\Windows\System32\Drivers\ Disk.sys), реализующий стандартную функциональность дисков. Windows также предоставляет разнообразные порт-драйверы дисков. Например, Scsi-port.sys — это порт-драйвер дисков, подключаемых к SCSI-шине, a Atapi.sys — порт-драйвер для систем на базе IDE. B Windows Server 2003 введен порт драйвер Storport.sys, заменяющий Scsiport.sys. Storport.sys был разработан для реализации функциональности высокопроизводительных аппаратных RAID-контроллеров и адаптеров Fibre ChanneI. Модель Storport аналогична Scsiport, что упрощает изготовителям задачу переноса существующих SCSI-минипортов под Storport. Минипорт-драйверы, создаваемые разработчиками для использования Storport, используют преимущества нескольких механизмов Storport, повышающих производительность, в частности поддержки параллельной инициации и завершения запросов на ввод-вывод в многопроцессорных системах, более управляемой архитектуры очереди запросов на ввод-вывод и выполнения большей части кода при более низком уровне IRQL, чтобы свести к минимуму длительность маскирования аппаратных прерываний.

Драйверы Scsiport.sys и Atapi.sys реализуют версию алгоритма планирования дисковых операций, известную под названием C–LOOK. Эти драйверы помещают запросы на дисковый ввод-вывод в списки с сортировкой по первому сектору, которому адресован запрос; этот сектор также называется номером логического блока (logical block number, LBN). C помощью функций KeInsertByKeyDeviceQueue и KeRemoveByKeyDeviceQueue (документированных в Windows DDK) они представляют запросы ввода-вывода как элементы (items) и используют начальный сектор запроса в качестве ключа, требуемого этими функциями. Обслуживая запросы, драйвер проходит по списку с самого младшего сектора до самого старшего. Достигнув конца списка, он возвращается в его начало, так как за это время в список могли быть вставлены новые запросы. Если адреса запросов распределены по всему диску, этот подход приводит к постоянному перемещению головок из начальной области диска к его концу. Storport.sys не реализует планирование дисковых операций, поскольку он в основном применяется для управления вводом-выводом, адресованным массивам накопителей, где нет четкого определения начала и конца диска.

C Windows поставляются некоторые минипорт-драйверы, включая Aha 154x.sys для SCSI-контроллеров семейства Adaptec 1540. B системах, где установлено минимум одно IDE-устройство на основе ATAPI, функциональность минипортов предоставляют драйверы Pciidex.sys и Pciide.sys. Один или несколько упомянутых драйверов присутствует в большинстве систем Windows.

iSCSI — это транспортный протокол для дисковых устройств, который интегрирует протокол SCSI с TCP/IP, благодаря чему компьютеры могут взаимодействовать с блочными накопителями, включая диски, по IP-сетям. Архитектура сети устройств хранения данных (storage area networking, SAN) обычно базируется на сети Fibre ChanneI, но администраторы могут использовать iSCSI для создания сравнительно недорогих SAN на основе таких сетевых технологий, как гигабитная Ethernet, что позволяет обеспечить масштабируемость, защиту от катастроф, эффективное резервное копирование и защиту данных. B Windows поддержка iSCSI реализуется в виде Microsoft iSCSI Software Initiator, который можно скачать с сайта Microsoft и который работает в Windows 2000, Windows XP и Windows Server 2003.

Microsoft iSCSI Software Initiator включает несколько компонентов.

• Initiator (инициатор) Этот необязательный компонент, состоящий из порт-драйвера iSCSI (\Windows\System32\Drivers\Iscsiprt.sys) и мини-порт-драйвера (\Windows\System32\Drivers\Msiscis.sys), использует драйвер TCP/IP для реализации программного iSCSI поверх стандартных Ethernet и TCP/IP при наличии сетевых адаптеров с аппаратным ускорением сетевых операций.

• Initiator Service (служба инициатора) Эта служба, реализованная в \Windows\System32\Iscsiexe.exe, управляет обнаружением и защитой всех инициаторов iSCSI, а также инициацией и завершением сеансов. Функциональность обнаружения устройств iSCSI реализована в \Windows\System32\Iscsium.dll и соответствует спецификации протокола Internet Storage Name Service (iSNS).

• Управляющие приложения K ним относятся IscsicIi.exe (утилита командной строки для управления соединениями iSCSI-устройств и их защитой) и соответствующий апплет для Control PaneI (Панель управления). Некоторые изготовители выпускают iSCSI-адаптеры с аппаратным ускорением операций по протоколу iSCSI. Служба инициатора работает с этими адаптерами, и они должны поддерживать iSNS, чтобы все iSCSI-устройства, в том числе обнаруженные как службой инициатора, так и iSCSI-оборудова-нием, можно было распознавать и контролировать через стандартные интерфейсы Windows.

У большинства дисковых устройств только один путь (path) между ними и компьютером — набор адаптеров, кабелей и коммутаторов. B серверах, требующих высокого уровня готовности к работе, применяются решения с несколькими путями — между компьютером и диском существует более одного набора соединительного оборудования, чтобы при аварии одного пути система все равно могла бы обращаться к диску по альтернативному пути. Однако без поддержки со стороны операционной системы или драйверов диск с двумя путями будет виден как два разных диска. Windows включает поддержку ввода-вывода по нескольким путям (muItipath I/O, MPIO) для управления дисками с несколькими путями как одним диском; эта поддержка опирается на сторонние драйверы — модули, специфичные для конкретного устройства (device-specific modules, DSM). Эти модули берут на себя всю специфику управления путями, в том числе политику балансировки нагрузки, на основе которой выбирается путь передачи запросов ввода-вывода, и механизмы обнаружения ошибок, уведомляющие Windows об аварии того или иного пути. Поддержка MPIO доступна для Windows 2000 Server, Advanced Server, Datacenter Server и Windows Server 2003 в виде Microsoft MPIO

Driver Development Kit, который лицензируется поставщиками аппаратного и программного обеспечения.

B стеке драйверов внешней памяти Windows MPIO (рис. 10-2) Multipath Disk Driver Replacement (\Windows\System32\Drivers\Mpdev.sys) заменяет функциональность стандартного драйвера класса Disk.sys. Mpdev.sys захватывает во владение объект «устройство», представляющий диски с несколькими путями, чтобы для таких дисков существовал лишь один объект «устройство». Кроме того, этот драйвер отвечает за поиск подходящего DSM для управления путями к устройству. Multipath Bus Driver (\Windows\System32\Drivers\Mpio.sys) управляет соединениями между компьютером и устройством, в том числе обеспечивая управление электропитанием данного устройства. Mpdev.sys уведомляет Mpio.sys о наличии устройств, которые тот должен контролировать. Наконец, Multipath Port Filter (\Windows\System32 \Drivers\Mpsfltr.sys) размещается поверх порт-драйвера для диска с несколькими путями и управляет информацией, передаваемой вверх по стеку устройств.

ЭКСПЕРИМЕНТ: наблюдение за вводом-выводом на физическом диске

C помощью механизма Event Tracing for Windows (см. главу 3) драйвера класса дисков утилита Diskmon от Sysinternals ведет мониторинг активности ввода-вывода на физических дисках и отображает ее в своем окне. Содержимое этого окна обновляется раз в секунду. Для каждой операции Diskmon показывает время, длительность, номер целевого диска, тип и смещение, а также длину.

Драйвер класса дисков создает объекты «устройство», представляющие диски и дисковые разделы. Имена таких объектов имеют вид \Device\HarddiskA\DRX, где X — номер диска. Для идентификации разделов и создания объектов «устройство», представляющих эти разделы, драйвер класса дисков в Windows 2000 использует функцию IoReadPartitionTable диспетчера ввода-вывода, а в Windows XP и Windows Server 2003 — функцию IoReadParitition-TableEx. Драйвер класса дисков вызывает одну из этих функций для каждого диска, представленного минипорт-драйвером драйверу класса на ранних стадиях загрузки системы. A функция инициирует дисковый ввод-вывод на уровне секторов, поддерживаемый драйвером класса, порт- и минипорт-драйверами, для считывания MBR- или GPT-таблицы разделов (об этом мы расскажем позже) и для формирования внутреннего представления жестких разделов диска. Драйвер класса дисков создает объекты «устройство», представляющие все главные разделы (в том числе логические диски внутри дополнительных разделов), которые этот драйвер получает IoReadPartitionTable или IoReadParititionTableEx. Вот пример имени объекта раздела:

\Device\Harddisk0\DP(1)0x7e000-0x7ff50c00+2

Это имя идентифицирует первый раздел первого диска системы. Два первых шестнадцатеричных числа (0x7e000 и 0x7ff50c00) определяют начало и длину раздела, а последнее число — внутренний идентификатор, назначенный драйвером класса.

Для совместимости с приложениями, использующими правила именования, принятые в Windows NT 4, драйвер класса дисков формирует для имен в формате Windows NT 4 символьные ссылки на объекты «устройство», созданные драйвером. Например, драйвер класса создает ссылки \Device\Harddisk0\PartitionO на \Device\Harddisk0\DRO и \Device\Harddisk0\Partitionl на объект «устройство» первого раздела первого диска. B Windows драйвер класса создает такие же символьные ссылки, представляющие физические диски, созданные в системах под управлением Windows NT 4. Так, ссылка \??\PhysicalDrive0 указывает на \Device\Harddisk0\DRO. Ha рис. 10-3 показана утилита Winobj (от Sysinternals), которая отображает содержимое каталога Harddisk базового диска.

Рис. 10-3. Окно Winobj, показывающее содержимое каталога Harddisk базового диска

Как вы уже видели в главе 3, Windows API ничего не знает о пространстве имен диспетчера объектов. Windows резервирует два подкаталога пространства имен, один из которых — подкаталог \Global?? (\?? в Windows 2000). (Другой подкаталог, \BaseNamedObjects, был рассмотрен в главе 3.) B этом подкаталоге объекты «устройство», включая диски, последовательные и параллельные порты, становятся доступными Windows-приложениям. Так как на самом деле объекты дисков находятся в других подкаталогах, для связывания имен в \GIobaI?? с объектами, расположенными в других каталогах пространства имен, Windows использует символьные ссылки. Диспетчер ввода-вывода создает ссылку \Global??\PhysicalDriveX для каждого физического диска системы; такая ссылка указывает на \Device\HarddiskX\Partition0 (где X — числа, начиная с 0). Windows-приложения, напрямую обращающиеся к секторам диска, открывают диск вызовом Windows-функции CreateFile и указывают в качестве параметра имя \\.\PhysicalDriveX (где X — номер диска). Прежде чем передать имя диспетчеру объектов, прикладной уровень Windows преобразует его в \Global??\PhysicalDriveX.

Диспетчер разделов (partition manager), \Windows\System32\Drivers\Partmgr.sys, отвечает за уведомление диспетчера Plug and Play (PnP) о наличии разделов; благодаря этому драйверы диспетчера томов (о них чуть позже) могут получать уведомления о создании и удалении разделов.

Для получения информации о разделах диспетчер разделов действует как функциональный драйвер применительно к объектам дисковых устройств, создаваемых драйвером класса дисков. При загрузке системы он считывает таблицы разделов подключенных дисков (в Windows 2000 через функцию ядра IoReadPartitionTable, а в Windows XP и Windows Server 2003 через такую же функцию IoReadPartitionTableEx) и сообщает об имеющихся разделах диспетчеру PnP Драйверы устройств диспетчера томов получают уведомление о разделах управляемых ими дисков и на основании сведений обо всех разделах, из которых состоят тома, определяют объекты «том». Диспетчер разделов отслеживает пакеты запросов на ввод-вывод (I/O request packets, IRP), относящиеся к модификации таблицы разделов, и поэтому может обновлять внутреннюю карту разделов, а затем уведомлять диспетчер PnP о создании и удалении любых разделов.

B Windows введена концепция базовых (basic) и динамических (dynamic) дисков. Диски с разбиением на разделы исключительно по схеме MBR или GPT в Windows называются базовыми. Поддержка динамических дисков впервые появилась в Windows 2000; они реализуют более гибкую схему разбиения на разделы, чем базовые. Фундаментальное различие между базовыми и динамическими дисками в том, что последние поддерживают создание составных томов (более производительных и надежных, чем простые тома). По умолчанию Windows управляет всеми дисками как базовыми — динамические диски надо создавать вручную или преобразованием из существующих базовых (если на них достаточно свободного места). Ho если вам не нужна функциональность составных томов, Microsoft рекомендует использовать именно базовые диски.

ПРИМЕЧАНИЕ Составные тома поддерживаются и на базовых дисках, но только если эти тома переносятся из Windows NT 4 (исключение составляет Windows Server 2003, которая в принципе не поддерживает составные тома на базовых дисках.) Ha портативных компьютерах — в силу ряда причин, в том числе из-за наличия только одного жесткого диска, который не предназначен для переноса между компьютерами, — Windows использует исключительно базовые диски. Кроме того, динамическими могут быть лишь фиксированные диски. Диски, подключенные к шинам IEEE 1394 или USB, а также диски, совместно используемые серверным кластером, всегда являются базовыми.

Эволюция управления внешней памятью началась с MS-DOS, первой операционной системы Microsoft. Когда емкость жестких дисков увеличилась, в MS-DOS нужно было ввести соответствующую поддержку. Поэтому первым шагом Microsoft стала организация в MS-DOS поддержки нескольких разделов, или логических дисков, на одном физическом диске. MS-DOS позволяла форматировать разделы с использованием различных файловых систем (FAT12 или FATl6) и назначать каждому разделу свою букву диска. Количество и размер разделов, которые можно было создавать в MS-DOS версий 3 и 4, были жестко ограничены, но уже в MS-DOS 5 схема разбиения на разделы стала вполне зрелой. MS-DOS 5 умела разбивать диски на любое число разделов произвольного размера.

Windows NT унаследовала схему разбиения жестких дисков на разделы, созданную для MS-DOS. Сделано это было из двух соображений: для совместимости с MS-DOS и Windows 3x, а также для того, чтобы команда разработчиков Windows NT могла опереться на проверенные средства управления дисками. Базовые концепции MS-DOS, относящиеся к разбиению дисков на разделы, в Windows NT были расширены для поддержки функций управления внешней памятью, необходимых операционной системе корпоративного класса, в частности для поддержки перекрытия дисков (disk spanning) и большей отказоустойчивости. B первой версии Windows NT, Windows NT 3.1, системные администраторы могли создавать тома, состоящие из нескольких разделов, что позволяло формировать тома большого размера из разделов нескольких физических дисков, а также повышать отказоустойчивость дисковой подсистемы за счет избыточности данных, организуемой программными средствами.

Хотя поддержка разбиения дисков на разделы по схеме MS-DOS в версиях Windows NT, предшествовавших Windows 2000, была достаточно гибкой для многих задач управления внешней памятью, у нее все же был ряд недостатков. Один из них в том, что активизация большинства изменений в конфигурации дисков требует перезагрузки системы. Ho современные серверы должны непрерывно работать в течение месяцев и даже лет, поэтому любая перезагрузка, даже плановая, крайне нежелательна. Другой недостаток связан с тем, что в Windows NT 4 информация о конфигурации томов, состоящих из нескольких разделов и созданных на основе MS-DOS-разделов, хранится в реестре. Это крайне затрудняет перенос конфигурационной информации при перемещении дисков между системами, а при переустановке операционной системы возможна и потеря этой информации. Наконец, требование назначать каждому тому уникальные буквы дисков из диапазона A-Z уже давно досаждало пользователям операционных систем Microsoft, ограничивая возможное количество локальных и подключенных сетевых томов.

Windows поддерживает три типа разбиения на разделы, которые позволяют преодолевать упомянутые ограничения: MBR (Master Boot Record), GPT (GUID Partition Table) и LDM (Logical Disk Manager).

B этом разделе описываются два типа разбиения на разделы — MBR и GPT, используемые Windows для определения томов на базовых дисках, — а также драйвер диспетчера томов (FtDisk), представляющий тома драйверам файловых систем. Если диспетчер дисков в Windows 2000 рекомендовал вам делать любой неразмеченный диск динамическим, то Windows XP и Windows Server 2003 автоматически определяют все диски как базовые.

Одно из требований к формату разбиения на разделы в Windows диктуется стандартными реализациями BIOS в системах: первый сектор основного диска должен содержать главную загрузочную запись (Master Boot Record, MBR). При запуске компьютера на базе x86-npoцeccopa BIOS считывает MBR и интерпретирует ее часть как исполняемый код. Выполнив предварительное конфигурирование оборудования, BIOS передает управление исполняемому коду в MBR для инициации процесса загрузки операционной системы.

B операционных системах Microsoft, включая Windows, MBR также содержит таблицу разделов. Таблица разделов состоит из четырех элементов, определяющих местонахождение на диске четырех главных разделов. B этой таблице указываются и типы разделов (которые определяют, какую файловую систему включает тот или иной раздел). Существует множество предопределенных типов разделов, например для FAT32 и NTFS. Раздел особого типа, дополнительный (extended partition), содержит еще одну MBR с собственной таблицей разделов. Эквивалент главного раздела в дополнительном называется логическим диском. Применение дополнительных разделов позволяет операционным системам Microsoft создавать любое количество разделов на диске (а не четыре на один диск).

Отличие главного раздела от логических дисков становится очевидным при загрузке Windows. Один из главных разделов основного жесткого диска должен быть помечен системой как активный. Код Windows, записываемый в MBR, загружает в память код первого сектора активного раздела (системного тома) и передает ему управление. Первый сектор такого раздела называется загрузочным. Кроме того, как уже говорилось в главе 4, у каждого раздела, отформатированного с использованием определенной файловой системы, имеется свой загрузочный сектор, который хранит информацию о структуре файловой системы данного раздела.

B рамках инициативы, направленной на создание стандартизированной и расширяемой платформы микрокода, которую операционные системы могли бы использовать в процессе своей загрузки, корпорация Intel разработала спецификацию EFI (Extensible Firmware Interface). EFI включает среду операционной мини-системы, реализуемую в виде микрокода, который, как правило, зашивается в ПЗУ. Эта среда используется операционной системой на ранних этапах для загрузки системных диагностических процедур и загрузочного кода. Первый процессор, поддерживающий EFI, — Intel IA64, поэтому версии Windows для IA64 используют EFI, но при желании позволяют выбрать и схему MBR. Детальное описание EFI см. по ссылке http://developer. intel.com/technology/efi.

EFI определяет схему разбиения на разделы — таблицу разделов GUID (GUID Partition Table, GPT), которая должна устранить некоторые недостатки схемы разбиения MBR. Например, адреса секторов, используемых структурами разделов GPT, вместо 32-разрядных стали 64-разрядными. 32-разрядные адреса обеспечивают доступ к 2 Тб памяти, но GPT разработана с прицелом на обозримое будущее. Среди прочих преимуществ GPT стоит отметить применение контрольных сумм CRC (cyclic redundancy checksums) для поддержания целостности таблицы разделов, а также резервное копирование таблицы разделов. GPT получила такое название из-за того, что кроме 36-байтового Unicode-имени она назначает каждому разделу свой GUID.

Ha рис. 10-4 показан пример структуры раздела GPT Как и в MBR-схеме, первый сектор GPT-диска содержит главную загрузочную запись, которая защищает этот диск от доступа операционных систем, не поддерживающих GPT Ho во втором и последнем секторах диска хранятся заголовки таблицы разделов GPT, а сама таблица размещается сразу за вторым сектором и перед последним сектором. Поддержка расширяемого списка разделов исключает необходимость во вложенных разделах, используемых в схеме MBR.

ПРИМЕЧАНИЕ Windows не поддерживает создание составных томов на базовых дисках, и новый раздел базового диска эквивалентен тому. Именно поэтому в оснастке Disk Management (Управление дисками) консоли MMC для обозначения тома, созданного на базовом диске, используется термин «раздел» (partition).

Драйвер FtDisk (\Windows\System32\Drivers\Ftdisk.sys) создает объекты «устройство» дисков для представления томов на базовых дисках и играет основную роль в управлении всеми томами на базовых дисках, включая простые тома. Для каждого тома FtDisk создает объект «устройство» вида \Device \Hard-diskVolumeX, гдеХ- число, которое идентифицирует том и начинается с 1.

Ha самом деле FtDisk является драйвером шины, поскольку отвечает за перечисление базовых дисков для обнаружения базовых томов и за оповещение о них диспетчера PnP. Определяя существующие разделы на базовых дисках, FtDisk использует диспетчер PnP и драйвер диспетчера разделов (Partmgr.sys). Диспетчер разделов регистрируется у диспетчера PnP, поэтому Windows может уведомить диспетчер разделов о том, что драйвер класса диска создал объект «устройство» раздела. Диспетчер разделов информирует FtDisk о новых объектах раздела через закрытый интерфейс и создает объекты «устройство» фильтра (filter device objects), которые потом подключает к объектам «устройство» разделов. При наличии объектов «устройство» фильтра Windows посылает диспетчеру разделов уведомление всякий раз, когда удаляется объект «устройство» раздела, что позволяет диспетчеру разделов обновлять информацию FtDisk. Драйвер класса дисков удаляет объект раздела при удалении раздела с помощью оснастки Disk Management консоли MMC Получив сведения о наличии разделов, FtDisk на основе информации о конфигурации базовых дисков определяет соответствие между разделами и томами, а затем создает объекты «устройство» томов.

Далее Windows создает в каталоге \Global?? (\?? в Windows 2000) диспетчера объектов символьные ссылки, указывающие на объекты томов, созданные FtDisk. Когда система или приложение впервые обращается к тому, Windows монтирует этот том, что позволяет драйверам файловых систем распознать и захватить во владение тома, отформатированные для поддерживаемых ими файловых систем (о монтировании см. раздел «Монтирование томов» далее в этой главе).

Мы уже упоминали, что динамические диски в Windows нужны для создания составных томов. За поддержку динамических дисков отвечает подсистема диспетчера логических дисков (Logical Disk Manager, LDM), состоящая из компонентов пользовательского режима и драйверов устройств. Microsoft лицензирует LDM у компании VERITAS Software, которая изначально разработала технологию LDM для UNIX-систем. Тесно сотрудничая с Microsoft, VERITAS перенесла LDM в Windows, благодаря чему эта операционная система получила более отказоустойчивую схему разбиения на разделы и средства поддержки составных томов. Главное отличие схемы разбиения на разделы LDM в том, что LDM поддерживает одну унифицированную базу данных, где хранится информация о разделах на всех динамических дисках системы, в том числе сведения о конфигурации составных томов.

ПРИМЕЧАНИЕ UNIX-версия LDM поддерживает и дисковые группы (disk groups): все динамические диски, включаемые системой в группу, используют общую базу данных. Однако коммерческое программное обеспечение VERITAS для управления логическими дисками в Windows поддерживает создание только одной дисковой группы.

База данных LDM размещается в зарезервированном пространстве (размером 1 Мб) в конце каждого динамического диска. Именно поэтому Windows требует свободное место в конце базового диска при его преобразовании в динамический. База данных LDM состоит из четырех областей, показанных на рис. 10-5: сектора заголовка, называемого в LDM «Private Header», таблицы оглавления, записей базы данных и журнала транзакций (пятый раздел на рис. 10-5 — просто зеркальная копия Private Header). Сектор Private Header размещается за 1 Мб до конца динамического диска и является границей базы данных. Работая с Windows, вы быстро заметите, что для идентификации практически всех объектов в ней используются GUID, и диски не составляют исключения. GUID — это 128-битное число, применяемое различными компонентами Windows для уникальной идентификации объектов. LDM назначает GUID каждому динамическому диску, а сектор Private Header регистрирует GUID динамического диска, на котором он находится, поэтому данные в Private Header относятся исключительно к конкретному диску. Private Header также хранит указатель на начало таблицы оглавления базы данных и имя дисковой группы, которое формируется конкатенацией имени компьютера и строки Dg0 (если имя компьютера — Daryl, то имя дисковой группы — DarylDg0). (Как уже говорилось, LDM в Windows поддерживает только одну дисковую группу, поэтому ее имя всегда оканчивается на DgO.) Для большей надежности LDM поддерживает копию Private Header в последнем секторе диска.

Таблица оглавления занимает 16 секторов и содержит информацию о структуре базы данных. Область записей базы данных LDM начинается с сектора заголовка записей базы данных сразу за таблицей оглавления. B этом секторе хранится информация об области записей базы данных, включая число присутствующих в ней записей, имя и GUID дисковой группы, к которой относится база данных, и идентификатор последовательности, используемый LDM для создания следующего элемента в базе данных. Секторы, следующие за сектором заголовка записей, содержат записи фиксированного размера (по 128 байтов) с описанием разделов и томов дисковой группы.

Элементы базы данных могут быть четырех типов: раздел (partition), диск (disk), компонент (component) и том (volume). Типы элементов определяют три уровня описания томов. LDM связывает элементы с помощью внутренних идентификаторов объектов. Ha самом нижнем уровне элементы разделов (partition entries) описывают нежесткие разделы, которые являются непрерывными областями на диске; идентификаторы, хранящиеся в элементе раздела, связывают его с элементами компонентов и дисков. Элемент диска (disk entry) представляет динамический диск в составе группы и включает его GUID. Элемент компонента (component entry) служит связующим звеном между одним или несколькими элементами разделов и элементом тома, с которым сопоставлен каждый раздел. Элемент тома хранит GUID этого тома, его суммарный размер, информацию о состоянии и букву диска. Элементы дисков, размер которых превышает размер одной записи, занимают несколько записей; элементы разделов, компонентов и томов редко занимают больше одной записи.

Простой том в LDM описывается тремя элементами: раздела, компонента и тома. Ниже показано содержимое простой базы данных LDM, которая определяет один том размером 200 Мб, состоящий из одного раздела.

Элемент раздела описывает область на диске, отведенную тому, элемент компонента связывает элемент раздела с элементом тома, а элемент тома содержит GIUD, используемый Windows на внутреннем уровне для идентификации тома. Для составных томов требуется более трех элементов. Например, чередующийся том (о них — позже) состоит минимум из двух элементов разделов, элемента компонента и элемента тома. Единственный том, который включает более одного элемента компонента, — зеркальный. Зеркальные тома включают два элемента компонентов, каждый из которых представляет половину зеркального тома. Когда вы разбиваете зеркальный том на разделы, LDM может разделить его на уровне компонентов, создав два тома, в каждом из которых будет по одному элементу компонента.

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

ЭКСПЕРИМЕНТ: просмотр базы данных LDM с помощью LDMDump

Утилита LDMDump (от Sysinternals) позволяет получить детальную информацию о содержимом базы данных LDM. Она принимает номер диска в качестве аргумента командной строки. Выводимая ею информация занимает несколько экранов, поэтому ее следует перенаправить в файл для последующего просмотра в текстовом редакторе (например: ldmdump /d0 › disk.txt). Ниже даны фрагменты выходной информации LDMDump. Первым показывается заголовок базы данных LDM, затем записи этой базы данных, которые описывают 4-гигабайтный диск с простым томом размером в 4 Гб. Элемент тома базы данных обозначен KaKVolumel. B конце вывода LDMDump перечисляет нежесткие разделы (soft partitions) и определения томов, найденные в базе данных.

Одно из первых действий при установке Windows на компьютер — создание раздела на основном физическом диске системы. B этом разделе Windows определяет системный том для хранения файлов, нужных на ранних этапах процесса загрузки. Кроме того, Windows Setup требует создать раздел для загрузочного тома, в который она запишет системные файлы Windows и где будет создан системный каталог (\Windows). Системный том можно сделать и загрузочным — тогда вам не понадобится создавать новый раздел для загрузочного тома. Терминология, используемая Microsoft для системного и загрузочного томов, может сбить с толку. Системным считается том, на который Windows помещает загрузочные файлы, включая загрузчик (Ntldr) и Ntdetect, а загрузочным — том, на котором Windows хранит основные системные файлы вроде Ntoskrnl.exe.

Хотя данные о разбиении динамического диска на разделы находятся в базе данных, LDM реализует и таблицу разделов в стиле MBR или GPT, чтобы загрузочный код Windows мог найти системный и загрузочный тома на динамических дисках. (Например, Ntldr и микрокод IA64 ничего не знают о LDM-разделах.) Если диск содержит системный и/или загрузочный тома, они описываются в таблице разделов в стиле MBR или GPT. B ином случае один раздел охватывает всю доступную для использования область диска. LDM помечает его как раздел типа «LDM»; поддержка разделов этого типа впервые появилась в Windows 2000. B пространстве, определенном в стиле MBR или GPT, LDM создает разделы, организуемые базой данных LDM.

Еще одна причина, по которой LDM создает таблицу разделов в стиле MBR или GPT, — чтобы унаследованные утилиты обслуживания дисков, включая работающие в средах с двухвариантной загрузкой, не решили, будто на динамическом диске не определены разделы.

Поскольку LDM-разделы не описываются таблицей разделов в стиле MBR или GPT, они называются нежесткими (soft partitions), а разделы в стиле MBR или GPT — жесткими (hard partitions). Рис. 10-6 иллюстрирует структуру динамического диска, размеченного в стиле MBR.

DLL оснастки Disk Management (DMDiskManager в Windows\System32\Dmdskmgr.dll), показанной на рис. 10-7, использует DMAdmin, службу LDM Disk Administrator (Windows\System32\Dmadmin.exe) для создания базы данных LDM и изменения ее содержимого. Когда вы запускаете оснастку Disk Management, в память загружается DMDiskManager, который запускает DMAdmin, если она еще не выполняется. DMAdmin считывает с каждого диска базу данных LDM и возвращает полученную информацию DMDiskManager. Если DMAdmin обнаруживает базу данных из дисковой группы другого компьютера, то отмечает, что эти тома находятся на удаленном диске, и позволяет импортировать их в базу данных текущего компьютера, если вы хотите их использовать. При изменении конфигурации динамических дисков DMDiskManager информирует DMAdmin о внесенных изменениях, и DMAdmin обновляет свою копию базы данных в памяти. Зафиксировав изменения, DMAdmin передает обновленную базу данных DMIO, драйверу устройства Dmio.sys. DMIO — эквивалент FtDisk для динамических дисков, так что он управляет доступом к базе данных на диске и создает объекты «устройство», представляющие тома на динамических дисках. Когда вы закрываете оснастку Disk Management, DMDiskManager останавливает и выгружает службу DMAdmin.

DMIO не знает, как интерпретировать базу данных, которой он управляет. За интерпретацию базы данных отвечают DMConfig (Windows\System32\ Dmconfig.dll), загружаемый DMAdmin, и DMBoot (Dmboot.sys), еще один драйвер устройства. DMConfig известно, как считывать и обновлять базу данных, a DMBoot — только как ее считывать. DMBoot загружается при загрузке системы, если другой драйвер LDM, DMLoad (Dmload.sys), обнаруживает в системе минимум один динамический диск. DMLoad определяет наличие динамических дисков, запрашивая DMIO. Если в системе есть хотя бы один динамический диск, DMLoad запускает DMBoot, который сканирует базу данных LDM. DMBoot информирует DMIO о составе каждого найденного им тома, что позволяет DMIO создать объекты «устройство» для представления томов. Закончив сканирование, DMBoot тут же выгружается из памяти. Поскольку в DMIO не заложена логика для интерпретации базы данных, его размер относительно невелик. Это несомненное преимущество, так как DMIO постоянно находится в памяти.

Как и FtDisk, DMIO является драйвером шины и создает объект «устройство» для каждого тома динамического диска, присваивая ему имя в виде \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolumeX, где Х- идентификатор тома, назначаемый DMIO. Кроме того, DMIO создает объект «устройство» с именем \Device\HarddiskDmVolumes\PhysicalDmVolumes\Raw-VolumeX, который представляет необработанный (неструктурированный) ввод-вывод на томе. Объекты «устройство», созданные DMIO в системе с тремя томами на динамических дисках, показаны на рис. 10-8. DMIO также создает в пространстве имен диспетчера объектов символьные ссылки на все тома, в том числе по одной ссылке для каждого тома в виде \Device\HarddiskDmVolumes\ComputerNameDg0\VolumeY. DMIO заменяет ComputerName именем компьютера, a Y — идентификатором тома (который отличается от внутреннего идентификатора, назначаемого драйвером DMIO объектам «устройство»). Эти ссылки указывают на объекты блочных устройств в каталоге PhysicalDmVolumes.

ПРИМЕЧАНИЕ B Windows 2000 имеется еще один драйвер — DiskPerf (\Windows\System32\Drivers\Diskperf.sys); он подключается к объектам «устройство», представляющим физические устройства (например, к \Device\Harddisk0\Partition0), что позволяет ему отслеживать запросы ввода-вывода, адресованные дискам, и генерировать статистические данные для соответствующих счетчиков оснастки Performance. B Windows XP и Windows Server 2003 функциональность DiskPerf реализована в драйвере диспетчера разделов, так как он уже фильтрует объекты дисковых устройств для поддержки своих основных функций, о которых мы рассказывали ранее.

FtDisk и DMIO отвечают за представление томов, управляемых драйверами файловой системы, и за перенаправление ввода-вывода, адресованного томам, в нижележащие разделы, составляющие тома. B случае простых томов диспетчер томов преобразует смещение в томе в смещение на диске, суммируя смещение в томе со смещением тома от начала диска.

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

B Windows поддерживаются следующие типы составных томов:

• перекрытые (spanned volumes);

• зеркальные (mirrored volumes);

• чередующиеся (striped volumes);

• RAID-5.

Рассмотрев конфигурацию разделов составных томов и логические операции для каждого типа составных томов, мы обсудим, как драйверы FtDisk и DMIO обрабатывают IRP, посылаемые драйвером файловой системы составному тому Термин «диспетчер томов» при объяснении составных томов используется для обозначения DMIO, поскольку, как уже говорилось в этой главе, FtDisk поддерживает лишь те составные тома, которые были перенесены из NT 4.

Перекрытый том — единый логический том, состоящий из нескольких (до 32) свободных разделов на одном или нескольких дисках. Оснастка Disk Management (Управление дисками) консоли MMC объединяет разделы в перекрытый том, который затем можно отформатировать для любой файловой системы, поддерживаемой Windows. Ha рис. 10-9 показан 100-мегабайтный перекрытый том с именем D:, созданный из последней трети первого диска и первой трети второго диска. B Windows NT 4 перекрытые тома назывались наборами томов (volume sets).

Перекрытый том удобен для объединения небольших областей свободного дискового пространства в единый том большего объема или для создания из нескольких малых дисков одного большого тома. Если перекрытый том отформатирован для NTFS, его можно расширять, добавляя другие свободные области или диски, и это не влияет на данные, уже хранящиеся на томе. Расширяемость — одно из самых крупных преимуществ описания всех данных на томе NTFS как единого файла. Размер логического тома NTFS может динамически увеличиваться, поскольку битовая карта, регистрирующая состояние тома, — не более чем еще один файл, файл битовой карты. Этот файл может быть расширен для учета пространства, добавляемого в том. C другой стороны, динамическое расширение тома FAT потребовало бы расширения самой FAT, что привело бы к смещению всех данных на диске.

Диспетчер томов скрывает физическую конфигурацию дисков от файловых систем, установленных в Windows. Например, на рис. 10-9 файловая система NTFS рассматривает том D: как обыкновенный 100-мегабайтный том. Чтобы определить свободное пространство на этом томе, NTFS обращается к своей битовой карте. Далее она вызывает диспетчер томов для чтения или записи данных с конкретного смещения в байтах относительно начала тома. Диспетчер томов последовательно нумерует физические секторы перекрытого тома от первой области первого диска до последней области последнего диска. Он определяет, какой физический сектор и на каком диске соответствует указанному смещению.

Чередующийся том — группа разделов (до 32), каждый из которых размещается на отдельном диске и объединяется в один логический том. Чередующиеся тома также называются томами RAID уровня 0, или томами RAID-0. Ha рис. 10–10 показан чередующийся том, состоящий из трех разделов, каждый из которых находится на отдельном диске. (Раздел чередующегося тома не обязательно занимает весь диск; единственное ограничение — все разделы на каждом диске должны быть одинаковы.)

Файловой системе этот чередующийся том кажется обычным 450-мегабайтным томом, но диспетчер томов оптимизирует хранение и выборку данных па таком томе, распределяя их между физическими дисками. Диспетчер томов обращается к физическим секторам дисков так, как показано на рис. 10–11.

Рис. 10–11. Логическая нумерация физических секторов в чередующихся томах

Поскольку каждая чередующаяся область занимает всего 64 Кб (это значение выбрано для того, чтобы отдельные операции чтения и записи не требовали обращения сразу к двум дискам), данные более-менее равномерно распределяются между дисками. Таким образом, чередование увеличивает вероятность того, что несколько одновременно ожидающих выполнения операций ввода-вывода потребуют доступа к разным дискам. A поскольку к данным на всех трех дисках можно обращаться одновременно, время задержки при дисковом вводе-выводе часто снижается, особенно в условиях высокой нагрузки.

Чередующиеся тома упрощают управление томами и позволяют распределять нагрузку между несколькими дисками, значительно ускоряя ввод-вывод. Ho это не обеспечивает восстановления данных в случае сбоя диска. B связи с этим диспетчер томов реализует три механизма избыточности: зеркальные тома, тома RAID-5 и замена секторов (последний механизм описывается в главе 12). Эти возможности можно задействовать через оснастку Disk Management.

B зеркальном томе содержимое раздела на одном диске дублируется в разделе равного размера на другом диске (рис. 10–12). Такие тома иногда называют томами RAID уровня 1, или томами RAID-1.

Когда программа что-то записывает на диск C:, диспетчер томов помещает те же данные в идентичный участок на зеркальный раздел. Если первый диск (или часть данных на нем) окажется поврежденной из-за аппаратного или программного сбоя, диспетчер томов автоматически обратится за нужными данными к зеркальному разделу. Зеркальный том можно отформатировать для любой файловой системы, поддерживаемой Windows. При этом драйверы файловых систем остаются независимыми — зеркалирование никак на них не влияет.

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

Зеркальный том — единственный тип составного тома, допустимого для системного и загрузочного томов. Дело в том, что загрузочный код Windows, включая код MBR и Ntldr, не обладает сложной логикой, необходимой для работы с составными томами. Зеркальные тома составляют исключение, так как загрузочный код воспринимает их как простые тома, считывая данные с той половины зеркального тома, которая помечена как загрузочный или системный диск в таблице разделов MBR. Поскольку загрузочный код не модифицирует данные на диске, он может игнорировать вторую половину зеркального тома.

ЭКСПЕРИМЕНТ: наблюдаем за операциями ввода-вывода на зеркальном томе

Используя оснастку Performance (Производительность), вы можете убедиться, что при записи на зеркальные тома данные копируются на оба диска, составляющих зеркальный том (зеркало), а операции чтения, если они не слишком частые, выполняются в основном на одной из половин зеркального тома. Для этого эксперимента вам понадобится система с тремя жесткими дисками под управлением серверной OC Windows 2000 или Windows Server 2003- Если у вас нет такой системы, пропустите инструкции по подготовке эксперимента и переходите сразу к результатам.

Создайте зеркальный том с помощью оснастки Disk Management.

1. Запустите Computer Management (Управление компьютером), раскройте узел Storage (Запоминающие устройства) и выберите папку Disk Management (Управление дисками) или откройте Disk Management как оснастку консоли MMC

2. Щелкните правой кнопкой мыши на свободном пространстве диска и выберите команду Create Volume (Создать том).

3. Следуйте инструкциям мастера создания тома, чтобы создать простой том. (Сначала убедитесь, что на другом диске достаточно свободного места для создания тома равного размера.)

4. Щелкните правой кнопкой мыши новый том и из контекстного меню выберите команду Add Mirror (Добавить зеркало).

Создав зеркальный том, запустите оснастку Performance (Производительность) и добавьте счетчики к объекту PhysicalDisk (Физический диск) для каждого экземпляра диска, содержащего раздел зеркального тома. Выберите счетчики Disk Reads/Sec (Обращений чтения с диска/сек) и Disk Writes/Sec (Обращений записи на диск/сек). Ha третьем диске, не входящем в состав зеркального тома, выберите большой каталог и скопируйте его на зеркальный том. Информация в окне оснастки Performance по мере выполнения операции копирования должна выглядеть примерно так, как показано на иллюстрации.

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

Том RAID-5 — отказоустойчивый вариант обычного чередующегося тома. B томах RAID-5 реализуется RAID уровня 5. Эти тома также называются чередующимися томами с записью четности (striped volumes with parity), поскольку они основаны на том же принципе чередования. Отказоустойчивость достигается за счет резервирования эквивалента одного диска для хранения информации о четности для всех чередующихся областей. Том RAID-5 представлен на рис. 10–13.

Как показано на рис. 10–13, информация о четности для чередующейся области 1 хранится на диске 1. Она представляет собой побайтовую логическую сумму (XOR) первых чередующихся областей на дисках 2 и 3. Информация о четности для чередующейся области 2 хранится на диске 2, а для чередующейся области 3 — на диске 3. Такое циклическое размещение информации о четности по дискам представляет собой способ оптимизации ввода-вывода. Всякий раз, когда данные записываются на какой-либо из дисков, байты четности, соответствующие изменяемым байтам, должны быть пересчитаны и перезаписаны. Если бы информация о четности постоянно записывалась на один и тот же диск, он был бы все время занят и мог бы стать узким местом для ввода-вывода.

Восстановление диска после сбоя в томе RAID-5 основывается на простом арифметическом принципе: если в уравнении с n переменными известны значения n — 1 переменных, то значение оставшейся переменной можно определить вычитанием. Например, в выражении x +y = z, где z обозначает чередующуюся область с четностью, диспетчер томов вычисляет z — у, чтобы определить значение x, и z — x, чтобы найти y. Диспетчер томов использует сходную логику для восстановления потерянных данных. Если том RAID-5 выходит из строя или данные на одном из его дисков становятся нечитаемыми, диспетчер томов реконструирует отсутствующие данные, используя операцию XOR (побитовое логическое сложение).

B случае сбоя диска 1 на рис. 10–13 содержимое его чередующихся областей 2 и 5 вычисляется побайтовым логическим сложением соответствующих чередующихся областей на диске 3 с областями четности на диске 2. Содержимое чередующихся областей 3 и 6 определяется побайтовым логическим сложением соответствующих областей на диске 2 с областями четности на диске 3. Для организации тома RAID-5 требуется по крайней мере три диска (а точнее, три одинаковых по размеру раздела на трех дисках).

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

Диспетчер монтирования, драйвер устройства Mountmgr.sys, назначает буквы томам динамических и базовых дисков, созданных после установки Windows, а также устройствам CD-ROM, приводам гибких дисков и съемным устройствам. Эта операционная система хранит все буквы дисков, назначенные томам, в разделе реестра HKLM\SYSTEM\MountedDevices. Заглянув в этот раздел, выувидите параметры с именами вида \??\Volume{X} (где X — GUID) и \DosDevices\C:. Такие параметры есть у каждого тома, но не всем томам назначены буквы дисков. Пример раздела реестра MountedDevices диспетчера монтирования показан на рис. 10–14. Заметьте, что этот раздел, как и раздел Disk в Windows NT 4, не входит в набор параметров управления и в связи с этим не восстанавливается при загрузке последней удачной конфигурации (см. главу 4).

Данные, которые хранятся в виде параметров реестра для букв и имен томов базовых дисков, представляют собой сигнатуру диска в стиле Windows NT 4 и начальное смещение от первого раздела, сопоставленного с томом. Аналогичные данные для томов динамических дисков включают внутренний GUID тома, используемый DMIO. Когда диспетчер монтирования инициализируется при загрузке системы, он регистрируется в подсистеме поддержки Plug and Play, что позволяет ему в дальнейшем получать уведомления о создании томов драйвером FtDisk или DMIO. Получив такое уведомление, диспетчер монтирования определяет GUID или сигнатуру диска нового тома и использует GUID тома или сигнатуру его диска как критерий для поиска в своей базе данных, отражающей содержимое раздела реестра MountedDevices. Если поиск заканчивается неудачей, диспетчер монтирования запрашивает у FtDisk или DMIO (смотря кто из них создал том) предлагаемую букву для идентификации тома и сохраняет ее в своей базе данных. FtDisk не дает никаких предложений, a DMIO проверяет возможные назначения в элементе тома базы данных.

Рис. 10–14. Смонтированные устройства, перечисленные в разделе реестра, принадлежащем диспетчеру монтирования

Если диспетчер монтирования не получает никаких предложений, он берет первую свободную букву, назначает ее тому, создает для нее символьную ссылку — например, \Global??\D: в Windows XP и Windows Server 2003 или \??\D: в Windows 2000 — и обновляет раздел реестра MountedDevices. Когда свободных букв нет, буква не назначается, но создается символьная ссылка \Global??\Volume{X}, определяющая GUID нового тома в том случае, если у него еще нет GUID. Этот GUID отличается от GUID томов, используемых DMIO.

Точки монтирования (mount points) позволяют связывать тома через каталоги NTFS, делая эти тома доступными без назначения букв дисков. Например, NTFS-каталог C: \Projects может монтировать другой том (NTFS или FAT), содержащий каталоги и файлы ваших проектов. Если в томе ваших проектов есть файл с именем \CurrentProject\Description.txt, то после монтирования путь к нему выглядит как C: \Projects\CurrentProject\Description.txt. Точки монтирования стали возможны благодаря технологии точек повторного разбора (reparse point technology), о которой мы подробно поговорим в главе 12.

Точка повторного разбора — это блок произвольных данных с неким фиксированным заголовком, который Windows сопоставляет с файлом или каталогом NTFS. Приложение или система определяет формат и поведение точки повторного разбора, в том числе значение уникального тэга, который идентифицирует точку повторного разбора, принадлежащую приложению или системе, и указывает размер (до 16 Кб) и смысл данных этой точки. Уникальные тэги хранятся в фиксированном сегменте точек повторного разбора. Любое приложение, реализующее точку повторного разбора, должно предоставлять драйвер фильтра файловой системы, который наблюдает за кодами возврата файловых операций, связанных с повторным разбором и выполняемых на томах NTFS, и предпринимает действия, соответствующие этим кодам. NTFS возвращает код статуса повторного разбора всякий раз, когда обрабатывает файловую операцию применительно к файлу или каталогу, с которым сопоставлена точка повторного разбора.

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

Пример приложения, поддерживающего точки повторного разбора, — система Hierarchical Storage Management (HSM) вроде службы Windows Remote Storage Service (RSS), которая включена в Windows 2000 Server и Windows Server 2003; она использует такие точки для обозначения файлов, перемещаемых администратором в хранилище на ленточных накопителях. Когда пользователь пытается обратиться к автономному файлу, драйвер фильтра HSM обнаруживает код статуса повторного разбора, возвращаемый NTFS, вызывает сервисы пользовательского режима, чтобы получить автономный файл из хранилища, удаляет из файла точку повторного разбора и инициирует повторную попытку выполнения файловой операции. Точно так же точки повторного разбора используются драйвером фильтра RSS (Rsfilter.sys).

Если файл или каталог, для которого диспетчер ввода-вывода получает от NTFS код статуса повторного разбора, не сопоставлен с одной из предопределенных в Windows точек повторного разбора, значит, его точка не обрабатывается ни одним драйвером фильтра. Тогда диспетчер ввода-вывода сообщает диспетчеру объектов об ошибке, которая передается приложению, обратившемуся к этому файлу или каталогу, в виде «file cannot be accessed by the system» («файл недоступен системе»).

Точки монтирования — это точки повторного разбора, в которых имя тома (\Global??\Volume{X}) хранится как данные повторного разбора. Назначая или удаляя пути для томов в оснастке Disk Management, вы создаете точки монтирования. Создавать и просматривать точки монтирования можно и с помощью встроенной утилиты командной строки Mountvol.exe (\Windows\System32\Mountvol.exe).

Диспетчер монтирования поддерживает на каждом томе NTFS удаленную базу данных, в которой регистрирует все точки монтирования, определенные для тома. Файл этой базы данных, $MountMgrRemoteDatabase, размещается в корневом каталоге NTFS. При перемещении диска между системами и в средах с двух вариантной загрузкой (различных систем Windows) перемещаются и точки монтирования — благодаря наличию удаленной базы данных диспетчера монтирования. NTFS отслеживает точки монтирования в файле метаданных \lExtend\IReparse (ни один из файлов метаданных NTFS не доступен приложениям). Поскольку NTFS хранит информацию о точках монтирования в файле метаданных, при соответствующем запросе Windows-приложения Windows может легко перечислить точки монтирования, определенные для тома.

ЭКСПЕРИМЕНТ: рекурсивные точки монтирования

Этот эксперимент с использованием утилиты Filemon {wwwsysinter nals.com) демонстрирует любопытное поведение системы, вызываемое рекурсивной точкой монтирования. Рекурсивной называется точка монтирования, связанная с тем томом, где она находится. Рекурсивное перечисление каталогов, выполняемое на рекурсивной точке монтирования, позволяет наглядно увидеть, как NTFS обрабатывает точки монтирования.

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

1. Откройте окно командной строки или Windows Explorer и создайте на NTFS-диске каталог с именем \Recurse.

2. B оснастке Disk Management (Управление дисками) консоли MMC щелкните том правой кнопкой мыши и выберите из контекстного меню команду Change Drive Letter And Path (Изменить букву диска или путь к диску).

3. B появившемся диалоговом окне введите путь к созданному вами каталогу (например, I: \Recurse).

4. Запустите Filemon. B меню Drives оставьте галочку только для тома, на котором создана точка монтирования.

Теперь вы готовы к трассировке рекурсивной точки монтирования. Откройте окно командной строки и введите dir /s I: \Recurse. Следите за ссылками на Recurse, регистрируемыми Filemon при трассировке файловых операций. Вы заметите, что сначала идет обращение к I: \Re-curse, затем к I: \Recurse\Recurse и т. д.

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

Filemon показывает запрос на открытие файла или каталога как IRP_ MJ_CREATE, запрос на закрытие файла или каталога — как IRP_MJ_CLOSE, а запрос сведений о каталогах — как IRP_MJ_DIRECTORY CONTROL, выполняемый с помощью функции FileBothDirectoryInfo (см. колонку Other).

Чтобы предотвратить переполнение буферов и вхождение в бесконечный цикл, командный процессор и Windows Explorer останавливают рекурсию по достижении 32-го уровня вложенности или при превышении длины пути в 256 символов — смотря что произойдет быстрее.

Тот факт, что Windows присваивает тому букву диска, еще не означает, что этот том содержит данные, организованные в формате файловой системы, известной Windows. Процесс распознавания тома заключается в том, что какая-либо файловая система объявляет раздел своим; первый раз этот процесс происходит при обращении ядра, драйвера устройства или приложения к какому-либо файлу или каталогу в данном томе. После того как драйвер файловой системы уведомляет о взятии на себя ответственности за управление разделом, диспетчер ввода-вывода направляет все адресованные этому тому запросы данному драйверу. Операции монтирования в Windows проходят в три этапа: регистрация драйвера файловой системы, обновление блоков параметров тома (volume parameter blocks, VPB) и запросы на монтирование.

ПРИМЕЧАНИЕ B Windows Server 2003 Enterprise и Datacenter Edition автоматическое монтирование отключено, чтобы не допустить агрессивного монтирования томов, подключенных к сети устройств хранения данных (System Area Network, SAN). Для включения или отключения автоматического монтирования можно использовать утилиту командной строки Diskpart, поставляемую с Windows Server 2003, а для монтирования томов вручную — утилиту Mountvol, также поставляемую с этой системой.

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

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

Например, если диспетчер монтирования назначает второму тому системы букву D, он создает символьную ссылку \Global??\D:, представляющую объект \Device\HarddiskVolume2. Windows-приложение, пытающееся открыть файл \Temp\Test.txt на диске D:, указывает имя D: \Temp\Test.txt, которое подсистема Windows преобразует в \Global??\D: \Temp\Test.txt перед вызовом NtCreateFile — процедуры ядра, отвечающей за открытие файла. NtCreateFile использует диспетчер объектов для разбора имени, и диспетчер объектов обнаруживает объект «устройство» \Device\HarddiskVolume2 с еще не разрешенным путем \Temp\Test.txt. Ha этом этапе диспетчер ввода-вывода проверяет, есть ли в VPB объекта \Device\HarddiskVolume2 ссылка на файловую систему. Если нет, диспетчер ввода-вывода выдает зарегистрированному драйверу файловой системы запрос на монтирование, чтобы выяснить, распознает ли он формат монтируемого тома как формат своей файловой системы.

ЭКСПЕРИМЕНТ: просмотр VPB

Увидеть содержимое VPB позволяет команда !vpb отладчика ядра. Поскольку на VPB указывает объект «устройство» тома, сначала нужно найти этот объект. Для этого создайте дамп объекта «драйвер» диспетчера томов, найдите объект «устройство», представляющий том, просмотрите его содержимое и вы обнаружите поле VPB.

Если в системе есть динамический диск, используйте команду !drvobj применительно к драйверу DMIO, а если нет — применительно к драйверу FtDisk. Вот пример:

Команда !drvobj перечисляет адреса объектов «устройство», принадлежащих драйверу. B этом примере таких объектов — семь. Один из них представляет программный интерфейс драйвера устройства, остальные — объекты томов. Поскольку объекты показываются в порядке, обратном порядку их создания, а первым создается объект «устройство» интерфейса драйвера устройства, то первый перечисленный объект «устройство» является объектом тома. Теперь введите команду !devobj отладчика ядра, указав в качестве параметра адрес объекта тома.

Команда !devobj показывает поле VPB объекта тома. (Данному объекту «устройство» присвоено имя HarddiskVolume6.) Теперь можно выполнить команду !vpb:

B итоге мы выяснили, что объект тома смонтирован драйвером файловой системы, который присвоил ему имя BACKUP. VPB-поле RealDevice указывает обратно на объект тома, а поле DeviceObject указывает на объект «устройство» смонтированной файловой системы.

По соглашению, драйвер файловой системы при распознавании формата монтируемого тома должен анализировать загрузочную запись тома, хранящуюся в его первом секторе. Загрузочные записи файловых систем Microsoft содержат поле, описывающее тип формата файловой системы. Драйверы файловых систем обычно проверяют это поле и, если оно указывает на поддерживаемый ими формат, анализируют остальную информацию, хранящуюся в загрузочной записи. Эта информация обычно включает имя файловой системы и данные, необходимые для поиска критически важных файлов метаданных тома. Например, NTFS распознает том, только если поля типа и имени определяют именно NTFS, а файлы метаданных, описываемые загрузочной записью, находятся в согласованном состоянии.

Если драйвер файловой системы подтверждает распознавание, диспетчер ввода-вывода заполняет VPB и передает запрос на открытие с оставшейся частью пути (т. е. \Temp\Test.txt) драйверу файловой системы. Последний выполняет запрос, интерпретируя данные в соответствии с форматом своей файловой системы. После того как поля VPB объекта «устройство» тома заполнены нужной информацией, диспетчер ввода-вывода передает все последующие запросы, адресованные данному тому, драйверу смонтированной файловой системы. Если ни один драйвер файловой системы не объявляет этот том своим, владельцем становится Raw — встроенный в Ntoskrnl.exe драйвер файловой системы, который сообщает о неудаче в ответ на любые попытки открыть файл в данном разделе. Рис. 10–15 иллюстрирует упрощенную схему потока ввода-вывода, направляемого на смонтированный том (здесь не показано взаимодействие драйвера файловой системы с диспетчерами кэша и памяти).

Вместо того чтобы загружать все драйверы файловых систем независимо от наличия соответствующих томов, Windows пытается свести к минимуму нагрузку на память, используя для предварительного распознавания файловой системы суррогатный драйвер File System Recognizer (Windows \System32\ Drivers\Fs_rec.sys). Этот драйвер знает о формате каждой файловой системы, поддерживаемой Windows, ровно столько, чтобы суметь проанализировать загрузочную запись и определить, можно ли ее сопоставить с какой-нибудь файловой системой Windows. При загрузке системы File System Recognizer регистрируется как драйвер файловой системы, а при вызове диспетчером ввода-вывода в процессе монтирования файловой системы для нового тома он загружает драйвер соответствующей файловой системы, если такой драйвер еще не загружен. После этого File System Recognizer перенаправляет IRP монтирования драйверу и позволяет ему захватить том во владение.

Кроме загрузочного тома, чей драйвер монтируется при инициализации ядра, драйверы файловых систем монтируют большинство томов в момент запуска Chkdsk для проверки целостности файловой системы на этапе загрузки системы. Загрузочная версия Chkdsk является встроенным приложением (в отличие от Windows-приложений) и называется Autochk.exe (\Windows \System32\Autochk.exe). Диспетчер сеансов (\Windows\System32 \Smss.exe) запускает ее, поскольку она указана в параметре HKLM\SYSTEM\Current-ControlSet\Control\Session Manager\BootExecute. Chkdsk перебирает все назначенные буквы диска, чтобы выяснить, требует ли соответствующий том проверки целостности.

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

Драйверы файловых систем управляют хранящимися в томах данными, но требуют поддержки диспетчера томов для взаимодействия с драйверами устройств внешней памяти при передаче данных. Драйверы файловых систем получают ссылки на объекты томов в процессе монтирования и посылают через них запросы диспетчеру томов. Приложения — если им нужно напрямую обращаться к данным тома — тоже могут посылать запросы диспетчеру томов, обходя драйвер файловой системы. K числу таких приложений относятся, например, программы восстановления удаленных файлов и утилита DiskProbe из ресурсов Windows.

Когда драйвер файловой системы или приложение посылает объекту «устройство», представляющему том, запрос ввода-вывода, диспетчер ввода-вывода перенаправляет этот запрос (поступающий в виде IRP) диспетчеру томов, создавшему целевой объект «устройство». Таким образом, если приложению нужно считать загрузочный сектор, например, второго простого тома в системе, оно открывает объект \Device\HarddiskVolume2 и посылает ему запрос на чтение 512 байтов по нулевому смещению на устройстве. Диспетчер ввода-вывода передает запрос приложения в виде IRP диспетчеру томов, владеющему данным объектом «устройство», и уведомляет его, что IRP адресован устройству HarddiskVolume2.

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

Роль диспетчера томов в обработке запросов к составным томам помогут прояснить следующие примеры. Если чередующийся том состоит из двух разделов (1 и 2), представленных объектом \Device\HarddiskDmVolumes\ PhysicalDmVolumes\BlockVolume3 (рис. 10–16), и администратор назначил чередующейся области букву диска D:, то диспетчер ввода-вывода определяет ссылку \Global??\D:, указывающую на \Device\HarddiskDmVolumes\ComputerNameDg0\Volume3, где ComputerName — имя компьютера. Вспомните, что эта ссылка также является символьной и указывает на соответствующий объект тома в каталоге PhysicalDmVolumes (в данном случае — на BlockVolu-me3). Объект «устройство», принадлежащий DMIO, перехватывает дисковый ввод-вывод файловой системы на \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3, и драйвер DMIO корректирует параметры запроса перед тем, как передать его драйверу класса дисков. B результате изменений, внесенных DMIO, запрос настраивается так, чтобы он ссылался на нужное смещение, относительное началу целевой чередующейся области раздела 1 или 2. Если ввод-вывод затрагивает оба раздела тома, DMIO должен выдать два дополнительных запроса ввода-вывода — по одному к каждому диску.

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

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

B Windows Server 2003 введена служба виртуального диска (Virtual Disk Service, VDS) (\Windows\System32\Vds.exe), которая предоставляет системным администраторам унифицированный высокоуровневый интерфейс внешней памяти; благодаря этому устройствами внешней памяти от разных поставщиков можно управлять через одни и те же пользовательские интерфейсы (UI). Схема VDS представлена на рис. 10–17. VDS экспортирует API, основанный на COM и позволяющий приложениям и сценариям создавать и форматировать диски, а также управлять аппаратными RAID-адаптерами. Скажем, утилита может задействовать VDS API для запроса списка физических дисков, сопоставленных с номером логического блока RAID (logical unit number, LUN). Windows-средства управления дисками, включая оснастку Disk Management консоли MMC, Diskpart и Diskraid (поставляется с Windows Server 2003 Deployment Kit), тоже используют VDS API.

VDS предоставляет два интерфейса: один — для провайдеров программного уровня, другой — для провайдеров аппаратного уровня.

• Провайдеры программного уровня (software providers) реализуют интерфейсы к таким высокоуровневым абстракциям устройств внешней памяти, как диски, разделы дисков и тома. Примеры операций, поддерживаемых этими интерфейсами, — расширение и удаление томов, включение и отключение зеркалирования, форматирование томов и присвоение им букв дисков. VDS ищет зарегистрированные программные провайдеры в HKLM\System\CurrentControlSet\Services\Vds\SoftwareProviders. Windows Server 2003 включает VDS Dynamic Disk Provider (\Windows\System32\ Vdsdyndr.dll), применяемый в качестве интерфейса для динамических дисков, и VDS Basic Provider (\Windows\System32\Vdsbas.dll), используемый в качестве интерфейса для базовых дисков.

• Провайдеры аппаратного уровня (hardware providers) реализуются изготовителями оборудования в виде DLL, которые регистрируются в разделе реестра HKLM\System\CurrentControlSet\Services\Vds\HardwareProvi-ders и которые транслируют аппаратно-независимые VDS-команды в команды, специфичные для конкретного оборудования. Провайдер аппаратного уровня позволяет управлять подсистемой внешней памяти, например аппаратным RAID-массивом или платами адаптеров/контроллеров, и поддерживает такие операции, как создание, расширение, удаление, маскирование и отмена маскирования LUN.

Когда приложение инициирует соединение с VDS API и служба VDS еще не запущена, процесс Svchost — хост службы RPC запускает процесс загрузчика VDS (\Windows\System32\Vdsldr.exe), а тот — процесс службы VDS, после чего завершается. После закрытия последнего соединения с VDS API завершается и процесс службы VDS.

Одно из ограничений многих утилит резервного копирования связано с открытыми файлами. Если приложение открывает какой-нибудь файл для монопольного доступа, утилита резервного копирования не может получить доступа к содержимому этого файла. Ho даже если подобная утилита способна обращаться к уже открытому файлу, нет никаких гарантий, что его резервная копия не окажется в рассогласованном состоянии. Допустим, приложение обновляет начальную часть файла, а потом что-то пишет в его конце. Утилита резервного копирования, которая сохраняет файл в ходе этих операций, может записать такой образ файла, который отражает еще не модифицированную начальную часть файла и уже измененную концевую часть. При последующем восстановлении этого файла приложение сочтет, что файл поврежден, поскольку оно допускает ситуации, в которых начальная часть уже изменена, а концевая — еще нет, но только не наоборот. Именно поэтому большинство утилит резервного копирования пропускает открытые файлы.

B связи с этим в Windows XP появилась служба теневого копирования томов (Volume Shadow Copy Service) (\Windows\System32\Vssvc.exe), которая позволяет встроенной утилите резервного копирования записывать согласованные представления всех файлов, в том числе открытых. Эта служба выступает в роли командного центра расширяемого механизма резервного копирования, давая возможность независимым поставщикам программного обеспечения (independent software vendors, ISV) подключать свои провайдеры и модули записи («writers»). Модуль записи — это программный компонент, позволяющий приложениям с поддержкой теневого копирования томов принимать уведомления о замораживании и размораживании операций записи, чтобы они могли создавать внутренне согласованные резервные копии своих файлов данных. A провайдеры позволяют ISV интегрировать уникальные схемы работы с внешней памятью со службой теневого копирования томов. Например, приложение, использующее устройства внешней памяти с зерка-лированием, могло бы определять теневую копию как замороженную половину зеркалированного тома. Взаимосвязи между службой теневого копирования томов, модулями записи и провайдерами показаны на рис. 10–18.

Рис. 10–18. Служба теневого копирования томов, модули записи и провайдеры

Microsoft Shadow Copy Provider (\Windows\System32\Drivers\Volsnap.sys) — это провайдер, поставляемый с Windows для поддержки программных снимков томов. Он представляет собой драйвер фильтра внешней памяти, размещаемый между драйверами файловых систем и драйверами томов (они оперируют с наборами секторов на жестком диске, представляющими логические диски), и поэтому видит любые запросы на ввод-вывод, адресованные дисковому тому. Утилита резервного копирования, приступая к копированию, указывает драйверу Microsoft Shadow Copy Provider создать теневые копии всех томов, на которых содержатся копируемые файлы и каталоги. Драйвер замораживает все операции ввода-вывода на этих томах и для каждого из них создает теневую копию. Если, например, том в пространстве имен диспетчера объектов имеет имя \Device\HarddiskVolumeO, то теневой том получает имя в виде \Device\HarddiskVolumeShadowCopy7V, где N — уникальный идентификатор.

ЭКСПЕРИМЕНТ: просмотр объектов «устройство», принадлежащих драйверу Microsoft Shadow Copy Provider

Чтобы просмотреть такие объекты, связанные с каждым томом, в Windows XP или Windows Server 2003, используйте отладчик ядра. B любой системе есть хотя бы один том, и следующая команда выводит информацию об объекте «устройство» для первого тома в системе:

Поле AttachedDevice в выводе команды !devobj сообщает адрес объекта «устройство» и имя владеющего им драйвера, который подключен к этому объекту (фильтрует его). Каждый объект «устройства» для тома должен принадлежать драйверу Volsnap, как в показанном примере.

Вместо того чтобы открывать копируемые файлы на исходном томе, утилита резервного копирования открывает их на теневом. Последний отражает представление тома, привязанное к определенной временной точке (point-in-time view of a volume). Поэтому, когда драйвер теневого копирования томов обнаруживает попытку записи на исходный том, он считывает копию подлежащих перезаписи секторов в раздел памяти, поддерживаемый страничным файлом (paging file-backed memory section) и сопоставленный с соответствующим теневым томом. Обращения для чтения к модифицируемым секторам теневого тома драйвер обслуживает через упомянутый выше раздел памяти, а обращения для чтения к немодифицированным секторам — считыванием данных с исходного тома. Поскольку утилита резервного копирования не сохраняет страничный файл и системный каталог \System Volume Information (вместе со всеми подкаталогами и файлами), драйвер снимков, используя API-функции дефрагментации, определяет местонахождение этих файлов и каталогов и не регистрирует вносимые в них изменения. Опираясь на данный механизм, утилита резервного копирования в Windows XP и Windows Server 2003 решает все проблемы копирования, связанные с открытыми файлами.

Рис. 10–19 иллюстрирует, как ведут себя приложение, обращающееся к тому, и утилита резервного копирования, обращающаяся к теневой копии этого тома. Когда приложение пишет в сектор по истечении времени снятия снимка, драйвер Volsnap создает резервную копию, как на иллюстрации, где он копирует секторы a, b и с для тома C:. Аналогично, когда приложение считывает сектор с, Volsnap направляет операцию чтения тому C:, а когда утилита резервного копирования считывает тот же сектор, Volsnap получает содержимое этого сектора из снимка. Если операция чтения требует обращения к немодифицированному сектору, например к d, то Volsnap направляет ее исходному тому.

ЭКСПЕРИМЕНТ: просмотр объектов «устройство» теневых томов

Вы можете убедиться в наличии таких объектов в пространстве имен диспетчера объектов, запустив Windows-утилиту резервного копирования [в меню Start (Пуск) откройте Accessories (Стандартные) и System Tools (Служебные)] и выбрав достаточный объем данных для резервного копирования, чтобы успеть запустить Winobj и просмотреть объекты в подкаталоге \Device.

Драйверы файловых систем должны корректно обрабатывать два запроса на управление вводом-выводом (IOCTL), связанные с теневым копированием томов: IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES и IOCTL_VOLSNAP_RELEASE_WRITES. Смысл этих запросов не требует объяснений — он понятен из их имен. API копирования теневых томов позволяет посылать IOCTL-запросы логическим дискам, для которых создаются снимки, с тем чтобы все операции записи, инициированные перед получением снимка, успели завершиться до создания теневой копии и чтобы файловые данные, записываемые из теневой копии, были согласованы по времени.

Поддержка теневого копирования томов позволяет Windows Server 2003 предоставлять конечным пользователям доступ к резервным версиям томов для восстановления старых версий файлов и папок, которые могли быть случайно удалены или изменены. Эта функция облегчает жизнь системным администраторам, которые в ином случае должны были бы загружать резервные данные и обращаться к предыдущим их версиям в интересах конечных пользователей.

B окне свойств для тома в Windows Server 2003 есть вкладка Shadow Copies (Теневые копии), на которой администратор может разрешить создание снимков томов по расписанию, как показано на следующей иллюстрации. Администраторы также могут ограничить пространство, выделяемое под снимки, чтобы система автоматически удаляла самые старые снимки.

B клиентских системах, где нужна функциональность Shadow Copies for Shared Folders, следует установить расширение Explorer — Previous Versions Client — которое поставляется c Windows Server 2003 в каталоге \Windows\System32\Clients\Twclient и которое также можно скачать с сайта Microsoft (это расширение включено в Windows XP Service Pack 2 и выше). Когда клиентская Windows-система с установленным расширением подключается к общей папке на томе, для которого имеются снимки, в окне свойств папок и файлов, находящихся в этой общей папке, появляется вкладка Previous Versions. Ha этой вкладке перечисляются снимки, имеющиеся на сервере, и пользователь может просмотреть соответствующие версии файла или папки.

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