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 может легко перечислить точки монтирования, определенные для тома.