Карты сотов

Ульи

На диске Registry хранится не в одном большом, а в нескольких отдельных файлах, называемых «ульями» (hive). Каждый улей содержит одну древовидную структуру Registry, имеющую свой корневой ключ (т. е. вершину дерева). Подключи и их значения находятся ниже корневого ключа в иерархии. Из сказанного можно было бы сделать вывод, что каждый корневой ключ, представленный в окне редактора Registry (regedit или regedt32), хранится в NT в отдельном улье, однако это не так. Соответствие между ключами, отображаемыми regedt32, и содержимым ульев не столь очевидно (см. табл. 1). В действительности ни один из этих корневых ключей не соответствует какому-либо одному улью. Соответствие ульев дисковым файлам представлено в табл. 2. Обратите внимание на отсутствие расширений. В тех случаях, когда имя файла не указано, логические корневые ключи являются объектами без дискового представления. Configuration Manager создает такие ключи для объединения различных ульев в структуру Registry, которая и отображается в окне regedt32.

Как явствует из табл. 1 и 2, некоторые ульи являются временными и обходятся без соответствующих файлов. Система создает их каждый раз при загрузке и хранит полностью в оперативной памяти, то есть они являются временными по самой своей природе. В качестве примера можно назвать улей HKEY_LOCAL_MACHINE\ HARDWARE, содержащий информацию о физических устройствах и зарезервированных для использования ими ресурсах. Определение аппаратной конфигурации и выделение ресурсов осуществляются каждый раз при загрузке системы, так что отказ от хранения этой информации на жестком диске представляется вполне логичным.

Таблица 1. Корневые ключи Regedit
Ключ	Описание
HKEY_CLASSES_ROOT	Символьная ссылка на ключ HKEY_LOCAL_MACHINE\SOFTWARE\Classes.
HKEY_CURRENT_USER	Символьная ссылка на один из ключей ветви, идущей от HKEY_USERS. Каждый такой ключ представляет один из ульев пользовательских параметров
HKEY_LOCAL_MACHINE	Временный ключ, не имеющий соответствующего физического улья. Объединяет корневые ключи различных ульев
HKEY_USERS	Временный ключ, объединяющий ульи параметров зарегистрированных в данный момент в системе пользователей
HKEY_CURRENT_CONFIG	Символьная ссылка на ключ текущего набора конфигурационных параметров аппаратуры, находящийся в ветви ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles
HKEY_DYN_DATA	Временный ключ, служащий для организации ускоренной выборки данных. Не имеет соответствующего физического улья

Сердце Registry — улей HKEY_ LOCAL_MACHINE\SYSTEM. В него входит подключ \CurrentControlSet\ Control, содержащий параметры, которые Configuration Manager использует при инициализации Registry. (В частности, значение ключа HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \hivelist используется при поиске файлов ульев.)

Таблица 2. Маршрутные имена ульев в Registry и соответствующие дисковые файлы
Маршрутное имя улья в Registry	Маршрутное имя файла улья
HKEY_LOCAL_MACHINE\SYSTEM	\winnt\system32\config\system
HKEY_LOCAL_MACHINE\SAM	\winnt\system32\config\sam
HKEY_LOCAL_MACHINE\SECURITY	\winnt\system32\config\security
HKEY_LOCAL_MACHINE\SOFTWARE	\winnt\system32\config\software
HKEY_LOCAL_MACHINE\HARDWARE	Временный улей
HKEY_LOCAL_MACHINE\SYSTEM\Clone	Временный улей
HKEY_USERS\UserProfile	Набор пользовательских параметров; обычно в каталоге \winnt\profiles\user
HKEY_USERS\.DEFAULT	\winnt\system32\config\default

Для соединения ульев в единое дерево Registry используются ключи специального типа символьная ссылка (symbolic link). Так, например, ключ HKEY_LOCAL_MACHINE\SAM является ссылкой на корневой ключ улья SAM.

Чтобы не обращаться к жесткому диску всякий раз, когда поступает запрос на доступ к Registry, в адресном пространстве ядра ОС хранится по копии каждого улья. В процессе инициализации улья Configuration Manager определяет размеры его файла, выделяет достаточное пространство в подкачиваемом пуле памяти ядра ОС и считывает в него файл улья. Подкачиваемый пул памяти — это область адресного пространства ядра NT, зарезервированная для использования драйверами устройств и самим ядром. Не используемые в данный момент фрагменты этого пула могут выгружаться в специальный файл подкачки.

Экран 1: Исследование рамки улья SYSTEM с помощью утилиты DiskProbe

Если бы размеры ульев никогда не увеличивались, Configuration Manager мог бы выполнять все операции на этой находящейся в памяти версии, так, словно улей не отличается от обычного файла. Расположение сота в памяти можно было бы вычислить, просто добавив к начальному адресу улья его индекс. Именно так поступает загрузчик Ntldr с ульем SYSTEM на одном из первых этапов загрузки операционной системы: Ntldr загружает улей SYSTEM целиком в память в режиме только для чтения и находит нужные соты по их смещению и начальному адресу улья. К сожалению, ульи растут с добавлением в них новых ключей и значений. Системе приходится выделять в своем подкачиваемом пуле дополнительные участки памяти для рамок, содержащих новые ключи и значения. Таким образом, данные Registry не обязательно размещаются в памяти все подряд.

Для работы с не непрерывными буферами, в которых хранятся в оперативной памяти ульи, Configuration Manager использует такую же стратегию, как Memory Manager — для установления соответствия адресных пространств виртуальной и физической памяти. На рис. 2. изображена двухуровневая схема вычисления адресов, содержащих сот блока и рамки по ее индексу (то есть ее смещению от начала улья). Напоминаю, что рамка может состоять из одного или более блоков, а наращивание ульев осуществляется целыми рамками, так что рамка всегда размещается в непрерывном буфере в памяти и все блоки одной рамки оказываются размещены в памяти подряд.

Рисунок 2: Схема использования индекса сота

Configuration Manager использует в схеме установления соответствия измененный индекс сота, состоящий из трех логических полей, — подобно тому, как Memory Manager делит на поля виртуальный адрес. Первое из этих полей NT интерпретирует как номер элемента каталога карт сот улья. Всего элементов в ней 1024, и каждый представляет собой ссылку на карту сотов — таблицу из 512 элементов. Второе поле индекса сота — номер элемента карты сот, содержащего адреса рамки и блока сота. Наконец, последнее поле индекса является смещением сота от начала блока. В процессе инициализации улья Configuration Manager динамически создает карты сот в таком количестве, чтобы общее число элементов в них было не меньше числа блоков в улье, а затем, при изменении размеров улья, добавляет или удаляет карты по мере надобности.

Дата добавления: 2014-12-07