История возникновения и развития реестра

Ключевые цели ReFS

Сохранить максимальную совместимость с набором широко используемых фич NTFS, и в то же время избавиться от ненужных, которые только усложняют систему

Верификация и автоисправление данных.

Максимальная масштабируемость.

Невозможность полного отключения файловой системы за счёт изоляции сбойных участков.

Гибкая архитектура с использованием функции Storage Spaces, которая задумана и реализована специально для ReFS.

 

Ключевые функции ReFS

(некоторые доступны только со Storage Spaces)

 

Целостность метаданных с контрольными суммами.

Integrity streams: метод записи данных на диск для дополнительной защиты данных при повреждении части диска.

Транзакционная модель "allocate on write" (copy on write)

Большие лимиты на размер разделов, файлов и директорий. Размер раздела ограничен 2⁷⁸ байт при размере кластера 16 КБ (2⁶⁴ * 16 * 2¹⁰), стек Windows поддерживает 2⁶⁴. Максимальное количество файлов в директории: 2⁶⁴. Максимальное количество директорий в разделе: 2⁶⁴.

Организация пулов и виртуализация для более простого создания разделов и управления файловой системой.

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

Поддержка техники чистки диска в фоновом режиме (disk scrubbing) для выявления скрытых ошибок.

Спасение данных вокруг повреждённого участка на диске.

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

В дополнение, ReFS унаследует многие функции и семантики NTFS, включая шифрование BitLocker, списки контроля доступа (ACL), журнал USN, уведомления об изменениях, символьные ссылки, точки соединения (junction points), точки монтирования (mount points), точки повторной обработки (reparse points), снимки тома, ID файлов и oplock.

Конечно же, данные с ReFS будут доступны для клиентов через те же APIs, которые используются сегодня во всех операционных системах для доступа к разделам NTFS.

 

24.Реестр. История разработки. Структура. Проблема *.ini.

 

Реестр Windows или системный реестр (англ. Windows Registry) — иерархически построенная база данных параметров и настроек в большинстве операционных систем Microsoft Windows.

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

Реестр Windows был введён для упорядочения информации, хранившейся до этого во множестве INI-файлов.

История возникновения и развития реестра

Реестр Windows 3.1

Сам реестр, как древовидная иерархическая база данных (registration database — регистрационная база) впервые появился в Windows 3.1 (апрель 1992). Это был всего один двоичный файл, который назывался REG.DAT и хранился в каталоге C:\Windows\. Реестр Windows 3.1 имел только одну ветку HKEY_CLASSES_ROOT. Он служил для связи DDE, а позднее иOLE объектов.

Одновременно c появлением реестра в Windows 3.1 появилась программа REGEDIT.EXE для просмотра и редактирования реестра.

Первый реестр уже имел возможность импорта данных из *.REG файлов. В базовой поставке шёл файл SETUP.REG, содержащий данные по основным расширениям и типам файлов.

Реестр Windows 3.1 имел ограничение на максимальный размер файла REG.DAT — 64 Кбайт. Если вдруг реестр превышал этот размер — то файл реестра (REG.DAT) приходилось удалять и собирать заново либо из *.REG файлов, либо вводить данные вручную.

[править] Реестр Windows NT 3.1

Следующий шаг сделан в Windows NT 3.1 (июль 1993). Произошёл отказ от устаревших файлов MS-DOS: AUTOEXEC.BAT и CONFIG.SYS, а также от INI-файлов, как от основных файлов конфигурации. На «регистрационную базу» (реестр) была переведена вся конфигурация системы. Основой конфигурации системы стал реестр. Он имел 4 корневых раздела: HKEY_ LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CLASSES_ROOT и HKEY_USERS.
Реестр стал «сборным»: на диске он хранился в файлах: DEFAULT, SOFTWARE, SYSTEM, а при запуске системы из этих файлов собиралась единая БД.
В комплекте поставки оставался файл REGEDIT.EXE, который по-прежнему позволял просматривать и редактировать только ветку HKEY_CLASSES_ROOT, и появился файл REGEDT32.EXE, который позволял редактировать все ветки реестра.

Далее технология и идеология (назначение) реестра уже не менялись. Все последующие версии Windows (NT 3.5, 95, NT 4.0, 98, 2000, XP, Vista, 7) использовали реестр как основную БД, содержащую все основные данные по конфигурации как самой ОС, так и прикладных программ. Далее менялись названия файлов реестра и их расположение, а также название и назначение ключей.

Реестр, по сути, это несколько файлов, хранящихся на жестком диске. Эти файлы находятся в %SystemRoot%\System32\Config, где %SystemRoot% - папка, куда установлена Windows. Еще один файл (Ntuser.dat), который создается для каждого пользователя и хранит его настройки находится в %SystemDrive%\Documents and Settings\%Username%, где %Username% - имя пользователя. Ниже перечислены имена файлов.

Проблемы *.ini файлов:

-INI-файлы не поддерживают Unicode

- INI-файлы не поддерживают точную настройку доступа

- Если у вас есть два записывающих потока, то это может привести к потере данных

- INI-файлы подвержены атакам отказа в обслуживании

- INI-файлы содержат только строки

- Парсинг INI-файла - это относительно медленная операция

- Многие программы открывают и работают с INI-файлами напрямую, минуя официальный API

- INI-файлы имеют ограничение в максимальный размер - не более 32 Кб

- Каталог по-умолчанию для INI-файлов - это папка Windows

- INI-файлы имеют только два уровня структуры

- Централизованное управление INI-файлами тяжело

 

25. Структура реестра. Ключи. Состав ключа

Структура реестра - см. предыдущий билет.

Ключи. Состав ключа.