Напомню, что архитектура хранения этой ОС базируется на старых, унаследованных от DOS, принципах построения разделов. Управление хранением в NT 4.0 имеет два существенных ограничения. Первое - это предел в 26 обслуживаемых томов в связи с тем, что система NT 4.0 может оперировать только буквами томов от A до Z. И второе ограничение: при создании набора томов, зеркального тома, чередующегося набора с четностью и без, чтобы изменения вступили в силу, необходима перезагрузка компьютера.

Aрхитектуры хранения Windows 2000 и NT 4.0 сильно различаются, и прежде всего тем, что описанные выше ограничения в Windows 2000 отсутствуют. Кроме того, здесь имеются и другие новые возможности, в частности система иерархического хранения HSM. Дальнейшее изучение деталей системы хранения в Windows 2000 поможет понять, как изменилась архитектура хранения NT 4.0.

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

Базовые диски против динамических

В Windows 2000 введены понятия базового и динамического дисков. Базовые диски построены с использованием схемы работы с разделами DOS, описанной в части 1. Другими словами, базовые диски являются унаследованными от Windows NT. Динамические диски представляют собой новый тип дисков в Windows 2000, они реализуют схему работы с разделами, которая будет описана ниже. Различие между базовым и динамическим дисками проявляется при обращении с томами, состоящими из нескольких разделов. Для базовых дисков вся информация о настройках сложных типов томов хранится в реестре; для динамических дисков эти данные сохраняются на диске. Такой способ хранения привязывает динамический диск к устройству хранения, на котором он определен.

Windows 2000 рассматривает все диски как базовые, до тех пор пока вручную не будет создан динамический диск или базовый диск (при наличии на нем достаточного объема свободного пространства) не будет конвертирован в динамический. Чтобы подтолкнуть администраторов к использованию динамических дисков, разработчики ввели для базовых дисков некоторые ограничения. Например, новые сложные типы томов можно создать только на динамических дисках (при проведении модернизации системы NT 4.0 существующие типы томов тем не менее поддерживаются). Другое ограничение позволяет в процессе работы наращивать объем тома NTFS только на динамических дисках. К сожалению, используемый динамическими дисками способ управления разделами несовместим с другими операционными системами, включая предыдущие версии Windows. Так, при создании системы с множественной загрузкой нельзя получить доступ к динамическому диску из другой ОС. В силу некоторых причин, в частности потому, что диски переносных компьютеров редко переставляются с одного компьютера на другой, на них Windows 2000 использует только базовый тип дисков.

Базовые диски

Хотя подход к управлению разделами базовых дисков в Windows 2000 не претерпел никаких изменений по сравнению с NT 4.0, способ, которым драйверы устройств управляют базовыми дисками, изменился. Как и в NT 4.0, драйверы хранения Windows 2000 построены по модели класс-порт-мини-порт. Как и в предыдущей версии, поставляется драйвер класса Disk, disk.sys, реализующий общие функции работы с дисками. Но, кроме него, Microsoft поставляет с Windows 2000 необходимые драйверы портов. Например, драйвер порта scsiport.sys для дисков на шине SCSI и pciidex.sys - драйвер порта для IDE-устройств. Имеется и несколько драйверов мини-портов, включая aha154x.sys, - для семейства SCSI-контроллеров Adaptec1540. В системах с хотя бы одним IDE-устройством на базе ATAPI один драйвер - atapi.sys - соединяет в себе функции порта и мини-порта.

Большинство установленных систем Windows 2000 использует один или несколько из упомянутых драйверов.

Прежде чем рассматривать управление дисками в Windows 2000, расскажу немного о том, как это происходит в NT 4.0. Драйвер класса Disk создает объект устройства с именем примерно такого вида DeviceHarddiskX Partition0; этот объект представляет физический диск, а вместо Х подставляется его номер. Когда драйвер класса обнаруживает диск, он вызывает функцию IoRead Partition менеджера ввода/вывода I/O Manager для сканирования таблицы разделов диска. Для каждого найденного раздела драйвер класса создает объект PartitionY в каталогe Harddisk (где Y указывает номер раздела). Функция ввода/вывода IoAssignDriveLetters формирует символическую ссылку в подкаталоге ?? менеджера объектов для каждого объекта «раздел устройства», и файловая система монтирует эти объекты, чтобы система и приложения получили доступ к разделам.

Для базовых дисков в Windows 2000 драйвер класса Disk также создает объекты, которые представляют диски и разделы; однако именование объектов и их роль изменены. Объекты, представляющие диски, имеют имена вида DeviceHarddiskXDRX; номер диска подставляется вместо обоих Х. Драйвер класса также использует функцию IoReadPartition для чтения таблицы разделов, но объекты «раздел диска» имеют более длинные имена. Например, имя объекта «раздел» может бытьDeviceHarddisk0DP(1)0x7e00-0x7ff50c00+2. Это имя указывает на первый раздел первого диска системы. Два шестнадцатеричных числа (0x7e00 и 0x7ff50c00) определяют начало и протяженность раздела, последнее число - внутренний идентификатор, присваиваемый драйвером класса.

Для обеспечения совместимости с приложениями, рассчитанными на систему имен NT 4.0, драйвер класса Disk создает символические ссылки в формате имен NT 4.0, которые указывают на объекты, организованные драйвером. Так, ссылка Device Harddisk0Partition0 указывает на DeviceHarddisk0DR0, а Device Harddisk0Partition1 - на первый объект «раздел» первого диска. Драйвер класса в Windows 2000 создает такие же символические ссылки Win32 для представления физических дисков, что и в NT 4.0. Так, ссылка ??PhysicalDrive0 указывает на DeviceHarddisk0DR0. На Экране 1 показано окно утилиты WinObj, где выведено содержимое каталога Harddisk для базового диска. Утилиту WinObj можно загрузить по адресу: http://sysinternals.com/winobj.htm ». На правой панели показаны объекты, соответствующие физическому диску и разделам.

Экран 1. Содержимое каталога DeviceHarddisk0.

В NT 4.0 объекты «раздел», создаваемые драйвером класса Disk, получают присвоенную им букву и монтируются файловыми системами. Windows 2000 делает то же самое несколько иначе. Драйвер FtDisk создает дисковые объекты, которые представляют тома на базовых дисках. Им назначаются буквы, которые и используются файловыми системами для монтирования. В NT 4.0 драйвер FtDisk применяется только при наличии хотя бы одного расширенного (дополнительного) раздела. В Windows 2000 FtDisk играет координирующую роль в управлении всеми томами базовых дисков, включая тома, которые не являются расширенными. В разделе HKEY_LOCAL_ MACHINESYSTEMDisk системного реестра хранится информация о базовых дисках, которая позволяет драйверу FtDisk определить, является раздел системы расширенным или нет. Для каждого тома FtDisk создает символическую ссылку вида Device HarddiskVolumeX, где Х - номер тома (начиная с 1). Такая ссылка указывает на объект «раздел», соответствующий тому или первому объекту типа раздел, если том состоит из нескольких разделов.

Версия FtDisk в Windows 2000 через менеджер разделов Partition Manager (partmgr.sys) задействует подсистему PnP, чтобы выяснить, существуют ли разделы на базовом диске. Менеджер разделов регистрируется в подсистеме PnP, так что Windows 2000 может информировать его о создании драйвером класса Disk объекта типа раздел устройства. Partition Manager сообщает драйверу FtDisk о новых объектах типа раздел и создает фильтр, который менеджер разделов прикрепляет к объектам. С помощью объекта типа фильтр Windows 2000 передает менеджеру Partition Manager информацию об удалении объекта типа раздел, чтобы тот мог обновить FtDisk. Драйвер класса Disk удаляет объект типа раздел при удалении раздела в оснастке (snap-in) Disk Management консоли ММС.

Назначение буквы диска для базовых дисков в Windows 2000 я опишу кратко. В ходе данного процесса создается соответствующая символическая ссылка в каталоге ??, которая указывает на объект типа том, созданный FtDisk. При доступе к тому операционной системы или приложения в первый раз, Windows 2000 выполняет операцию монтирования так же, как в NT 4.0. Аналогично FtDisk перехватывает пакеты с запросами на ввод/вывод (IRP), направленные томам из нескольких разделов, и соответствующим образом обрабатывает их. FtDisk различает запросы на чтение, направленные зеркальному тому, и служебные запросы, направленные набору томов, используя измененные IRP, специфичные для каждого набора разделов. Если система направляет запрос IRP обычному, нерасширенному тому, FtDisk просто перенаправляет его драйверу класса Disk.

Динамические диски

Как уже было сказано, динамические диски, необходимые для создания новых типов сложных томов, являются предпочтительным типом дисков в Windows 2000. Подсистема логического менеджера дисков Logical Disk Manager (LDM), состоящая из компонентов пользовательского режима и драйверов устройств, ответственна за динамические диски. LDM был лицензирован Microsoft у компании VERITAS Software, которая первоначально разработала эту технологию для UNIX. Совместно с Microsoft компания VERITAS перенесла LDM в Windows 2000, чтобы реализовать в ней новые возможности управления разделами. Механизмы управления разделами в стиле DOS и в стиле LDM различаются прежде всего тем, что LDM управляет одной унифицированной базой, хранящей информацию обо всех динамических дисках системы, включая настройку расширенных разделов. Версия LDM для UNIX оперирует понятием дисковой группы, которая объединяет все динамические диски системы, разделяющие одну общую базу данных. Полная коммерческая версия программного обеспечения VERITAS для Windows 2000 также реализует дисковые группы, но встроенная в Windows 2000 версия работает только с одной дисковой группой.

База данных LDM размещается в зарезервированной области размером 1 Мбайт в конце каждого динамического диска. Соответственно, для выполнения конвертации в конце каждого базового диска должно быть свободное пространство. И хотя данные о разделах динамических дисков хранятся в базе данных LDM, менеджер дисков создает и обычную DOS-таблицу разделов, чтобы унаследованные утилиты управления дисками, включая те, что работают под Windows 2000, и те, которые функционируют под управлением других ОС, в случае системы с многовариантной загрузкой ошибочно не посчитали динамический диск неразбитым на разделы. Таблица разделов нужна также для того, чтобы программа загрузки Windows 2000 могла находить системный и загрузочный тома, даже если они расположены на динамических дисках (загрузчик NT Loader - NTLDR - не имеет информации о разбиении LDM). Если диск содержит системный или загрузочный тома, разделы указывают на расположение этих томов. В противном случае один раздел начинается на первом цилиндре диска (при 63 секторах на диске) и продолжается до начала базы данных LDM. В этой области разделов и создаются разделы LDM, информация о которых хранится в базе данных диска. На Рисунке 1 представлена схема построения динамического диска.

Рисунок 1. Схема структуры динамического диска.

База данных LDM состоит из четырех областей (см. Рисунок 2): сектора заголовка, называемого в LDM личным заголовком (Private Header); таблицы содержимого; записей базы данных и журнала транзакций. Сектор с Private Header располагается за 1 Мбайт до конца динамического диска и фиксирует местоположение базы данных. По мере освоения Windows 2000 становится очевидно, что система использует GUID для идентификации всего, чего только можно, и дисков в том числе. LDM присваивает каждому динамическому диску свой GUID, и заголовок Private Header отмечает у себя идентификатор динамического диска, на котором он расположен (он потому и называется «личным», что содержит приватную информацию о диске). В этом заголовке хранятся также имя дисковой группы, которое образуется добавлением Dg0 к имени компьютера (например, DesktopDg0, если имя компьютера Desktop), и указатель на начало таблицы с содержимым базы. В целях защиты от сбоев LDM сохраняет копию Private Header в последнем секторе диска.

Рисунок 2. Структура базы данных LDM.

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

Запись базы данных может быть одного из четырех типов: раздел, диск, компонент и том. LDM использует указанные типы записей и трехуровневую систему описания томов, сопоставляя записи базы данных с внутренними идентификаторами объектов. На самом нижнем уровне записи типа раздел описывают смежные области на диске; идентификаторы, сохраняемые в записи о разделе, указывают на записи типа компонент и диск. Запись типа диск представляет динамический диск в составе дисковой группы и содержит GUID диска. Запись типа компонент служит связующим звеном между одной или более записями о разделах и записью о томе, с которым ассоциированы данные разделы. Запись о томе хранит GUID тома, его общий размер, состояние и возможный буквенный идентификатор. Запись типа диск размером более 178 байт размещается в нескольких записях БД; длина записей типов раздел, компонент, том редко бывает больше стандартной.

Рисунок 3. База данных LDM, описывающая один 200-мегабайтный том.

Для описания простого тома LDM нужно три записи: запись о разделе, запись типа компонент и запись о томе. На Рисунке 3 представлено содержимое простой базы LDM, которая определяет один 200-мегабайтный том на одном разделе. Запись о разделе описывает область на диске, выделенную системой для тома, запись типа компонент соединяет записи о разделе и томе, а запись о томе содержит GUID, используемый внутри Windows 2000 для идентификации тома. Более сложные тома требуют более трех записей. Например, чередующийся набор имеет как минимум две записи о разделах, запись типа компонент и запись о томе. Только зеркальный том может иметь более одной записи типа компонент; он имеет две компонентные записи, каждая из которых отвечает за свою половину зеркала. Две записи типа компонент в случае зеркального тома используются LDM для того, чтобы при удалении тома этого типа можно было разделить его на уровне составляющих том дисков и создать два тома уже с одной записью типа компонент для каждого из них. Если простой том требует три записи, а база размером 1 Мбайт может содержать примерно 8000 таких записей, значит, предельное число томов, которое можно создать в Windows 2000, составит примерно 2500.

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

Управление динамическими дисками

Модуль консоли ММС winntsystem32dmconfig.sys (DMConfig) создает и изменяет содержимое базы данных LDM. При запуске программы управления дисками Disk Management модуль DMConfig загружается в память и считывает базу LDM с каждого диска. При обнаружении базы данных дисковой группы другого компьютера он отмечает, что тома на диске чужие и дает возможность импортировать их в базу данных текущего компьютера, если это необходимо. При изменении конфигурации динамических дисков DMConfig изменяет копию базы в памяти системы и передает ее DMIO - драйверу dmio.sys. DMIO выполняет функции FtDisk для динамических дисков, он управляет доступом к базе на диске и создает объекты, представляющие тома на динамических дисках.

DMIO не отвечает за интерпретацию базы, которую он обслуживает, - это забота DMConfig и еще одного драйвера, dmboot.sys (DMBoot). DMConfig знает, как читать и как изменять базу; DMBoot - только как ее читать. DMBoot загружается при старте системы, если третий LDM-драйвер - dmload.sys (DMLoad) - определяет, что в системе представлен по меньшей мере один динамический диск. Опрашивая DMIO, драйвер DMLoad выясняет, есть ли динамические диски, и при наличии такого диска запускает DMBoot, который в свою очередь считывает содержимое базы данных LDM. DMBoot возвращает DMIO состав каждого из имеющихся в базе томов, и тот может создать объекты, представляющие каждый том. Сразу после завершения сканирования базы DMBoot выгружается из памяти. DMIO не имеет в своем составе логики интерпретации базы, и поэтому его размер относительно мал. Это очень важно, поскольку данный модуль постоянно загружен в память.

Экран 2. Объекты устройств, созданные DMIO.

DMIO создает объект типа устройство для каждого тома динамического диска с именем вида DeviceHarddisk DmVolumesPhysicalDmVolumesBlockVolumesX, где X - идентификатор, присваиваемый DMIO тому. Кроме того, драйвер создает другой объект, представляющий потоковый (неструктурированный) ввод/вывод для тома с именем DeviceHarddiskDmVolumesPhysicalDmVolumes RawVolumesX. На Экране 2 показаны объекты, созданные DMIO на системе с двумя томами на динамических дисках. В пространстве имен Object Manager также создаются символические ссылки для каждого тома, начиная от DeviceHarddiskDm VolumesComputerNameDg0VolumeY. DMIO заменяет ComputerName именем компьютера, а Y - идентификатором тома (отличным от внутреннего идентификатора, присваиваемого DMIO-объектам). Ссылки указывают на объекты типа блочное устройство в каталоге PhysicalDm Volumes. DMIO управляет пакетами IRP почти так же, как FtDisk, поскольку он отслеживает разделы, составляющие том и тип тома, который представляют объекты устройства. Однако, так как драйвер класса Disk работает только с разделами DOS, DMIO должен выполнить простые трансформации вида «раздел в диск» для того, чтобы FtDisk передал управление драйверу класса Disk. Когда система или приложение выполняют операции с файловой системой на динамическом томе, управляющий драйвер файловой системы направляет пакет IRP объекту устройства DMIO, который представляет том. Если IRP направлен простому тому, DMIO пересчитывает в нем смещение относительно раздела в смещение относительно диска и передает IRP драйверу класса Disk. Но если пакет IRP направлен на составной том, DMIO может создать дополнительные пакеты ввода/вывода или выполнить более сложную настройку смещения и длины. Например, при получении пакета на запись объекту устройства, представляющему зеркальный том, DMIO посылает IRP объектам типа устройство драйвера класса Disk для тех физических дисков, которые составляют зеркало.

Один из типов составных томов в Windows 2000 - это набор томов, подобный набору томов в NT 4.0, но тот не может быть расширен без перезагрузки. Новые возможности NTFS для расширения размера томов, включая изменение файлов метаданных, снимают это ограничение. DMIO также полностью поддерживает создание составных томов, а именно зеркальных томов и томов с чередованием, без последующей перезагрузки системы.

Точки повторной обработки

Я выделил освобождение от привязки к буквам дисков в Windows 2000 как одну из самых примечательных особенностей новой системы хранения. Новый механизм, точки монтирования, позволяет задавать имена каталогов томам NTFS, что дает возможность не назначать томам букв. Так, каталог NTFS с именем c:Projects может быть смонтирован к другому тому (NTFS или FAT), содержащему каталоги и файлы проекта. Если на томе имеется файл CurrentProject Description.txt, можно получить к нему доступ, указав путь c:ProjectsCurrentProjectDescription.txt. Использование точек монтирования стало возможным благодаря технологии точек повторной обработки (reparse points).

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

Драйвер файловой системы, менеджер ввода/вывода I/O Manager и менеджер объектов Object Manager все вместе реализуют механизм обработки reparse points. Object Manager начинает операции разбора полного имени файла (путь плюс имя файла), используя I/O Manager в качестве интерфейса к драйверам файловой системы. Поэтому он должен возвращать операции, для которых I/O Manager возвращает код статуса обработки. Менеджер ввода/вывода выполняет модификацию полного имени, которая может потребоваться точкам монтирования или другим типам точек повторной обработки, а драйвер файловой системы NTFS должен ассоциировать точку с конкретными файлами или каталогами с указанием ее данных. Таким образом, I/O Manager играет роль драйвера-фильтра точек повторной обработки для файловой системы, реализующего многие определенные Microsoft reparse points.

Примером приложения, использующего точки повторной обработки, может служить система иерархического хранения HSM, в которой reparse points применяется для указания файлов, определенных администратором для переноса на ленты. При попытке получить доступ к такому файлу драйвер фильтра HSM определяет код статуса, возвращаемый NTFS, взаимодействует со службой пользовательского режима для извлечения файла из хранилища, снимает reparse point с файла и возобновляет файловую операцию над файлом после его подстановки. Так обращается с точками повторной обработки драйвер фильтра Remote Storage Manager (RSM), rsfilter.sys.

Если менеджер I/O Manager получает код статуса обработки от NTFS и файл или каталог, для которых данный код возвращался, не ассоциирован ни с одной из встроенных в Windows 2000 точек повторной обработки, то драйвер фильтра, ответственный за данную точку, не обнаруживается. В этом случае менеджер ввода/вывода возвращает менеджеру объектов ошибку вида File cannot be accessed by the system error («Отсутствует доступ к файлу из-за системной ошибки») для приложения, осуществлявшего доступ к файлу или каталогу.

Точки подсоединения и точки монтирования

Разработчики Microsoft не решились использовать символические ссылки на файлы в NT, поскольку многие Windows-программы не могли корректно обрабатывать их. Например, в случае удаления файла-ссылки программа могла непреднамеренно удалить не саму ссылку, а файл, на который она указывает.

Известно, что любая разновидность UNIX поддерживает символические ссылки, указывающие на файл или каталог, расположенный где-либо еще. В NT такие ссылки использовались в реестре и широко применялись в пространстве имен менеджера объектов Object Manager. Но до появления Windows 2000 ни одна файловая система NT ссылки не поддерживала. В новой версии введены символические ссылки на каталог, в терминах Microsoft - точки подсоединения NTFS. Это заранее определенные точки повторной обработки, ассоциированные с пустым NTFS-каталогом. Они содержат имя какого-либо другого каталога системы. При указании пути к файлу, проходящего через точку подсоединения, NTFS возвращает I/O Manager код статуса обработки для каталога, ассоциированного с точкой подсоединения, и менеджер ввода/вывода определяет данную точку как точка подсоединения. Менеджер восстанавливает имя каталога, хранящееся в области данных точки подсоединения, и вызывает внутреннюю функцию, IopDoName Transmogrify. Эта функция изменяет заданный ранее путь к файлу и возвращает код статуса обработки менеджеру объектов. При получении этого кода Object Manager повторяет запрос с измененным именем, и NTFS снова выполняет поиск.

В Windows 2000 нет никаких инструментов для создания точек подсоединения. Можно использовать linkd, утилиту из Windows 2000 Resource Kit или загрузить Junction, написанный мною клон linkd, с http://sysinternals.com/misc.htm.

Точки монтирования похожи на точки подсоединения - они имеют даже одинаковый тег обработки, - но в области данных вместо имени каталога хранят имя тома (например, ??Volume{X}).

При использовании Disk Management в консоли ММС для назначения или удаления каталога монтирования тома как раз и создаются точки монтирования. Это можно сделать с помощью встроенной команды mountvol, создающей точки монтирования и выводящей информацию о них.

Менеджер монтирования

Назначение дискам букв - еще один аспект системы хранения, который претерпел изменения в Windows 2000. NT 4.0 хранит соответствующие дискам буквы в разделе HKEY_LOCAL_ MACHINESYSTEMDisk, и менеджер ввода/вывода NT выполняет функцию IoAssignDriveLetters в ходе загрузки. Данная функция запускает процесс назначения букв, в ходе которого создаются ссылки в каталоге ?? менеджера объектов и выполняются все присваивания, сделанные через Disk Administrator.

IoAssignDriveLetters в Windows 2000 работает аналогично NT 4.0, но назначает буквы только томам на базовых дисках, поскольку лишь они задействуют механизм разделов из DOS, который используется и в NT 4.0. Новый драйвер, менеджер монтирования Mount Manager (mountmgr.sys), присваивает буквы томам на динамических дисках и тем простым томам, что были созданы после старта системы. Все сделанные присваивания хранятся в разделе HKEY_LOCAL_MACHINE SYSTEMMountedDevices. Заглянув в него, можно увидеть параметры с именами ??Volume{X} (где X - идентификатор GUID) и ??C:. Каждый том имеет запись с именем тома, не обязательно запись с присвоенной ему буквой. На Экране 3 приведен пример содержимого раздела реестра для Mount Manager.

Экран 3. Пример содержимого раздела реестра HKEY_LOCAL_MACHINESYSTEMMountedDevices.

Данные, хранящиеся в реестре для назначенных букв и имен томов базовых дисков, - это сигнатуры дисков в стиле NT 4.0, а также начальное смещение первого раздела, связанного с томом. Данные в реестре для томов на динамических дисках включают внутренний GUID от DMIO тома. При инициализации менеджера монтирования в процессе загрузки он регистрируется в подсистеме PnP и таким образом получает уведомления при создании тома посредством FtDisk или DMIO. При получении уведомления Mount Manager определяет GUID нового тома или сигнатуру диска, а затем запрашивает у FtDisk или DMIO (в зависимости от того, кто создал том) назначенную букву. FtDisk возвращает HKEY_LOCAL_MACHINESYSTEMDisk (если система была модернизирована от NT 4.0 к Windows 2000), а DMIO ищет ссылку на букву в записях базы данных тома. Если буква не найдена, менеджер монтирования использует сигнатуру диска или GUID тома для поиска в своей внутренней базе данных, содержащей копию раздела реестра. Внутренняя база просматривается на предмет наличия присвоенной тому буквы. Если ее нет, Mount Manager использует первую свободную букву (если они есть), выполняет новое присваивание, создает для него символическую ссылку (типа ??D) и обновляет раздел реестра MountedDevices. Одновременно он создает символическую ссылку для тома (типа ??Volume{X}), задающую новый GUID тома, если тот не имеет идентификатора. Данный идентификатор отличается от GUID, используемого внутри DMIO.

На каждом томе NTFS менеджер монтирования управляет также базой Mount Manager Remote Database, в которую записывает любые точки монтирования, определенные на данном томе. Файл базы данных, :$MountMgr RemoteDatabase, размещается в корневом каталоге NTFS. Точки монтирования перемещаются при переносе диска с одной системы на другую и в системах с двойной загрузкой (при загрузке одной из нескольких установленных на компьютере систем Windows 2000), как раз при помощи Mount Manager Remote Database. NTFS отслеживает точки монтирования в файле метаданных NTFS $Extend$Reparse. В нем хранится вся информация, относящаяся к точкам монтирования, и поэтому Windows 2000 может просмотреть все такие точки, относящиеся к данному тому, когда какое-либо приложение Win32, например Disk Manager, требует описания точек монтирования.

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

МАРК РУСИНОВИЧ

доктор философии в области вычислительной техники Университета Карнеги-Меллон и один из соавторов многих популярных утилит для Windows NT, включая NTFSDOS, Filemon, Regmon и Recover. С ним можно связаться по электронной почте по адресу: mark@sysinternals.com, или через Web-узел http://www.sysinternals.com.