Ntfs изнутри как устроена файловая таблица mft в windows

Устройство файловой системы NTFS поражает своей грандиозностью и напоминает огромный, окутанный мраком лабиринт. Но какого любителя приключений остановит паутина, скелеты и пара ловушек с ядовитыми стрелами? Хватай факел, и отправимся в путь. Нашим первым квестом будет изучение главной файловой таблицы — MFT и нескольких дочерних структур.

Стандарт файловой системы NTFS версии 3.1 появился в 2001 году с выходом на рынок Windows XP и с тех пор не претерпел фундаментальных изменений. В Windows 10 также используется NTFS v3.1. Архитектуру и особенности внутреннего устройства этой файловой системы Крис Касперски подробно описал в своей книге «Восстановление данных», которая сейчас готовится к переизданию. Мы публикуем отрывок из этой книги, где Крис рассказывает о том, что представляет собой NTFS изнутри.

Основным структурным элементом всякой файловой системы является том (volume), в случае с FAT совпадающий с разделом (partition). NTFS поддерживает тома, состоящие из нескольких разделов (см. рис.). Будем для простоты считать, что том представляет собой отформатированный раздел (то есть раздел, содержащий служебные структуры файловой системы).

Большинство файловых систем трактуют том как совокупность файлов, свободного дискового пространства и служебных структур файловой системы, но в NTFS все служебные структуры представлены файлами, которые (как это и положено файлам) могут находиться в любом месте тома, при необходимости фрагментируя себя на несколько частей.

Основным служебным файлом является главная файловая таблица, $MFT (Master File Table) — своеобразная база данных, хранящая информацию обо всех файлах тома — их именах, атрибутах, способе и порядке размещения на диске. Каталог также является файлом особого типа, со списком принадлежащих ему файлов и вложенных подкаталогов. Важно подчеркнуть, что в MFT присутствуют все файлы, находящиеся во всех подкаталогах тома, поэтому для восстановления диска наличия файла
$MFT будет вполне достаточно.

Остальные служебные файлы, называемые метафайлами (metafiles) или метаданными (metadata), всегда имеют имена, начинающиеся со знака доллара (
$), и носят сугубо вспомогательный характер, интересный только самой файловой системе. К ним в первую очередь относится:
$LogFile — файл транзакций,
$Bitmap — карта свободного/занятого пространства,
$BadClust — перечень плохих кластеров и т. д. Текущие версии Windows блокируют доступ к служебным файлам с прикладного уровня (даже с правами администратора!), и всякая попытка открытия или создания такого файла в корневом каталоге обречена на неудачу.

Классическое определение, данное в учебниках информатики, отождествляет файл с именованной записью на диске. Большинство файловых систем добавляет к этому понятие атрибута (attribute) — некоторой вспомогательной характеристики, описывающей время создания, права доступа и т. д. В NTFS имя файла, данные файла и его атрибуты полностью уравнены в правах. Иначе говоря, всякий файл NTFS представляет собой совокупность атрибутов, каждый из которых хранится как отдельный поток байтов. Поэтому, во избежание путаницы, атрибуты, хранящие данные файла, часто называют потоками (streams).

РЕКОМЕНДУЕМ:
Как отключить время последнего доступа к файлу в NTFS Windows 10

Каждый атрибут состоит из тела (body) и заголовка (header). Атрибуты подразделяются на резидентные (resident) и нерезидентные (non-resident). Резидентные атрибуты хранятся непосредственно в
$MFT, что существенно уменьшает грануляцию дискового пространства и сокращает время доступа. Нерезидентные атрибуты хранят в
$MFT лишь свой заголовок, описывающий порядок размещения атрибута на диске.

Назначение атрибута определяется его типом (type), представляющим собой четырехбайтное шестнадцатеричное значение. При желании атрибуту можно дать еще и имя (name), состоящее из символов, входящих в соответствующее пространство имен (namespace). Подавляющее большинство файлов имеет по меньшей мере три атрибута. К их числу относится стандартная информация о файле (время создания, модификации, последнего доступа, права доступа), которая хранится в атрибуте типа
10h, условно обозначаемом
$STANDARD_INFORMATION. Ранние версии Windows NT позволяли обращаться к атрибутам по их условным обозначениям, но начиная с Windows 2000 мы лишены этой возможности. Полное имя файла (не путать с путем!) хранится в атрибуте типа
30h (
$FILE_NAME).

Если у файла есть одно или несколько альтернативных имен, таких атрибутов может быть и несколько. Здесь же хранится ссылка (file reference) на родительский каталог, позволяющая разобраться, к какому каталогу принадлежит данный файл или подкаталог. По умолчанию данные файла хранятся в безымянном атрибуте типа
80h (
$DATA). Однако при желании прикладные программы могут создавать дополнительные потоки данных, отделяя имя атрибута от имени файла знаком двоеточия (например:
ECHO xxx > file:attr1; ECHO yyy > file:attr2; more < file:attr1; more < file:attr2).

Изначально в NTFS была заложена способность индексации любых атрибутов, значительно сокращающая время поиска файла по заданному списку критериев (например, времени последнего доступа). Индексы хранятся в виде двоичных деревьев, поэтому среднее время выполнения запроса оценивается как
O(lg n). На практике в большинстве драйверов NTFS реализована индексация лишь по имени файла. Как уже говорилось ранее, каталог представляет собой файл особого типа — файл индексов. В отличие от FAT, где файл каталога представляет собой единственный источник данных об организации файлов, в NTFS файл каталога используется лишь для ускорения доступа к содержимому каталога. Он не является обязательным, так как ссылка на родительский каталог всякого файла в обязательном порядке присутствует в атрибуте его имени (
$FILE_NAME).

Каждый атрибут может быть зашифрован, разрежен или сжат. Техника работы с такими атрибутами выходит далеко за рамки первичного знакомства с организацией файловой системы. Мы же рассмотрим углубленно фундамент файловой системы NTFS — структуру
$MFT.

Главная файловая таблица

В процессе форматирования логического раздела в его начале создается так называемая зона MFT (см. рис.). По умолчанию она занимает 12,5% от емкости тома (а не 12%, как утверждается во многих публикациях), хотя, в зависимости от значения параметра
NtfsMftZoneReservation, она может составлять 25, 37 или 50%.

В этой области расположен файл
$MFT, изначально занимающий порядка 64 секторов и растущий от начала зоны MFT к ее концу по мере создания новых пользовательских файлов и каталогов. Чем больше файлов содержится на томе, тем больше размер MFT. Приблизительный размер файла
$MFT можно оценить по следующей формуле:
sizeof(FILE Record) N Files, где
sizeof(FILE Record) обычно составляет 1 Кбайт, а
N Files — полное количество файлов и подкаталогов раздела, включая недавно удаленные.

Для предотвращения фрагментации файла
$MFT зона MFT удерживается зарезервированной вплоть до полного исчерпания свободного пространства тома, затем незадействованный «хвост» зоны MFT усекается в два раза, освобождая место для пользовательских файлов. Этот процесс может повторяться многократно, вплоть до полной отдачи всего зарезервированного пространства. Решение красивое, хотя и не новое. Многие из файловых систем восьмидесятых годов прошлого века позволяли резервировать заданное дисковое пространство в хвосте активных файлов, сокращая их фрагментацию (причем любых файлов, а не только служебных). Например, такая способность была у DOS 3.0, разработанной для персональных компьютеров типа «Агат». Может быть, кто-то из вас помнит такую машину?

Когда файл
$MFT достигает границ зоны MFT, в ходе своего последующего роста он неизбежно фрагментируется, вызывая обвальное падение производительности файловой системы. При этом стоит заметить, что подавляющее большинство дефрагментаторов файл
$MFT не обрабатывают! А ведь API дефрагментации, встроенный в штатный драйвер NTFS, обеспечивает такую возможность!

При необходимости файл
$MFT может быть перемещен в любую часть диска, и тогда в начале тома его уже не окажется. Стартовый адрес файла
$MFT хранится в загрузочном секторе по смещению
30h байт от его начала. B подавляющем большинстве случаев этот адрес ссылается на четвертый кластер.

Файл
$MFT представляет собой массив записей типа
FILE Record (в терминологии UNIX они называются inodes), каждая из которых описывает соответствующий ей файл или подкаталог. На практике один файл или подкаталог полностью описывается единственной записью типа
FILE Record, хотя в теории этих записей может потребоваться и несколько.

Для ссылки на одну файловую запись из другой используется ее порядковый номер (он же индекс) в файле
$MFT, отсчитываемый от нуля. Файловая ссылка (file reference) состоит из двух частей (см. табл.) — 48-битного индекса и 16-битного номера последовательности (sequence number).

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

Первые 12 записей в MFT всегда занимают служебные метафайлы:
$MFT (собственно сам файл
$MFT),
$MFTMirr (зеркало
$MFT),
$LogFile (файл транзакций),
$Volume (сведения о дисковом томе),
$AttrDef (определения атрибутов),
‘.’ (корневой каталог),
$Bitmap (карта свободного пространства),
$Boot (системный загрузчик),
$BadClus (перечень плохих кластеров) и т. д.

Первые четыре записи настолько важны, что продублированы в специальном файле
$MFTMirr, находящемся примерно в середине тома (точный адрес этого файла хранится в загрузочном секторе по смещению
38h байт от его начала). Вопреки своему названию, файл
$MFTMirr — это отнюдь не «зеркало» всего файла
$MFT, а всего лишь резервная копия первых четырех его элементов.

Записи с 12-й по 15-ю помечены как используемые, в то время как в действительности они пусты. Как несложно догадаться, они зарезервированы для использования в будущем. Записи с 16-й по 23-ю не задействованы и честно помечены как неиспользуемые.

Начиная с 24-й записи располагаются пользовательские файлы и каталоги. Четыре метафайла, впервые появившихся в Windows 2000, —
$ObjId,
$Quota,
$Reparse и
$UsnJrnl — могут располагаться в любой записи, номер которой равен 24 или больше (не забудь, что нумерация файловых записей начинается с нуля).

Файловые записи

Структурно файловая запись состоит из заголовка (header) и одного или нескольких атрибутов (attributes) произвольной длины, завершаемых маркером конца (end marker) — четырехбайтным шестнадцатеричным значением
FFFFFFFFh. Несмотря на то что количество атрибутов и их длина меняются от одной файловой записи к другой, размер самой структуры
FILE Record строго фиксирован. В большинстве случаев он равен 1 Кбайт (это значение хранится в файле
$boot, причем первый байт файловой записи всегда совпадает с началом сектора).

Если реальная длина атрибутов меньше размеров файловой записи, то ее «хвост» просто не используется. Если же атрибуты не умещаются в отведенное им пространство, создается дополнительная файловая запись (extra FILE Record), ссылающаяся на свою предшественницу. Так выглядит структура файловой записи:

Первые четыре байта заголовка заняты «магической последовательностью»
FILE, сигнализирующей о том, что мы имеем дело с файловой записью типа
FILE Record. При восстановлении сильно фрагментированного файла
$MFT это обстоятельство играет решающую роль, поскольку позволяет отличить сектора, принадлежащие MFT, от всех остальных секторов.

Следом за сигнатурой идет 16-разрядный указатель, содержащий смещение последовательности обновления (update sequence). Под «указателем» здесь и до конца раздела подразумевается смещение от начала сектора, отсчитываемое от нуля и выраженное в байтах. Последовательность обновления хранится по смещению
002Dh, и поэтому сигнатура приобретает следующий вид:
FILE—x00.

Размер заголовка варьируется от одной версии операционной системы к другой и в явном виде нигде не хранится. Вместо этого в заголовке присутствует указатель на первый атрибут, содержащий его смещение в байтах относительно начала файловой записи и расположенный по смещению
14h байт от начала сектора.

Смещения последующих атрибутов (если они есть) определяются путем сложения размеров всех предыдущих атрибутов (размер каждого из атрибутов содержится в его заголовке) со смещением первого атрибута. За концом последнего атрибута находится маркер конца — значение
FFFFFFFFh.

Длина файловой записи хранится в двух полях. Тридцатидвухразрядное поле реального размера (real size), находящееся по смещению
18h байт от начала сектора, содержит совокупный размер заголовка, всех его атрибутов и маркера конца, округленный по 8-байтной границе. Тридцатидвухразрядное поле выделенного размера (allocated size), находящееся по смещению
1Сh байт от начала сектора, содержит действительный размер файловой записи в байтах, округленный по размеру сектора. Документация утверждает, что выделенный размер должен быть кратен размеру кластера, но на практике это не так. Например, на моей машине длина поля выделенного размера равна четверти кластера.

16-разрядное поле флагов, находящееся по смещению
16h байт от начала сектора, в подавляющем большинстве случаев принимает одно из следующих трех значений:
00h — данная файловая запись не используется или ассоциированный с ней файл или каталог удален,
01h — файловая запись используется и описывает файл,
02h — файловая запись используется и описывает каталог.

64-разрядное поле, находящееся по смещению
20h байт от начала сектора, содержит индекс базовой файловой записи. Для первой файловой записи это поле всегда равно нулю, а для всех последующих, расширенных записей — индексу первой файловой записи. Расширенные файловые записи могут находиться в любых областях MFT, не обязательно расположенных рядом с основной записью. Следовательно, необходим какой-то механизм, обеспечивающий быстрый поиск расширенных файловых записей, принадлежащих данному файлу (просматривать всю MFT было бы слишком нерационально). Этот механизм существует, и основан он на ведении списков атрибутов (
$ATTRIBUTE_LIST). Список атрибутов представляет собой специальный атрибут, добавляемый к первой файловой записи и содержащий индексы расширенных записей.

Последовательность обновления

Будучи очень важными компонентами файловой системы,
$MFT,
INDEX и
$LogFile нуждаются в механизме контроля целостности своего содержимого. Традиционно для этого используются коды обнаружения и коррекции ошибок (ECC/EDC codes). Однако на тот момент, когда проектировалась NTFS, процессоры были не настолько быстрыми, как теперь, и расчет корректирующих кодов занимал значительное время, существенно снижающее производительность файловой системы. Именно поэтому от использования корректирующих кодов пришлось отказаться. Вместо них разработчики NTFS применили так называемые последовательности обновления (update sequences), также называемые fix-ups.

В конец каждого из секторов, образующих файловую запись (
INDEX Record,
RCRD Record или
RSTR Record), записывается специальный 16-байтный номер последовательности обновления (update sequence number), дублируемый в заголовке файловой записи. При каждой операции чтения два последних байта сектора сверяются с соответствующим полем заголовка, и, если драйвер NTFS обнаруживает расхождение, данная файловая запись считается недействительной.

Основное назначение последовательностей обновления — защита от «обрыва записи». Если в процессе записи сектора на диск исчезнет питающее напряжение, может случиться так, что часть файловой записи будет записана успешно, а другая часть сохранит прежнее содержимое (файловая запись, как мы помним, обычно состоит из двух секторов). После восстановления питания драйвер файловой системы не может уверенно определить, была ли файловая запись сохранена целиком. Вот тут-то последовательности обновления и выручают! При каждой перезаписи сектора последовательность обновления увеличивается на единицу. Потому, если произошел обрыв записи, значение последовательности обновления, находящейся в заголовке файловой записи, не совпадет с последовательностью обновления, расположенной в конце сектора.

Оригинальное содержимое, расположенное «под» последовательностью обновления, хранится в специальном массиве обновления (update sequence array), расположенном в заголовке файловой записи непосредственно за концом смещения последовательности обновления (update sequence number). Для восстановления файловой записи в исходный вид необходимо извлечь из заголовка указатель на смещение последовательности обновления (он хранится по смещению
04h байт от начала заголовка) и сверить лежащее по этому адресу 16-байтное значение с последним словом каждого из секторов, слагающих файловую запись (
INDEX Record,
RCRD Record или
RSTR Record). Если они не совпадут, значит, соответствующая структура данных повреждена. Использовать такие структуры следует очень осторожно (на первых порах лучше не использовать вообще).

По смещению
006h от начала сектора находится 16-разрядное поле, хранящее совокупный размер номера последовательности обновления вместе с массивом последовательности обновления (
sizeof(update sequence number) + sizeof(update sequence array)), выраженный в словах (не в байтах!). Так как размер номера последовательности обновления всегда равен одному слову, то размер массива последовательности обновления, выраженный в байтах, должен вычисляться следующим образом:
(update sequence number & update sequence array 1)*2. Таким образом, смещение массива оригинального содержимого равно
(offset to update sequence number) + 2.
В Windows XP и более новых операционных системах эти значения располагаются по смещениям
2Dh и
2Fh соответственно. Первое слово массива последовательности обновления соответствует последнему слову первого сектора файловой записи или индексной записи. Второе — последнему слову второго сектора и т. д.

Атрибуты

Структурно всякий атрибут состоит из атрибутного заголовка (attribute header) и тела атрибута (attribute body). Заголовок атрибута всегда хранится в файловой записи, расположенной внутри MFT. Тела резидентных атрибутов хранятся там же. Нерезидентные атрибуты хранят свое тело вне MFT, в одном или нескольких кластерах, перечисленных в заголовке данного атрибута в специальном списке. Если 8-разрядное поле, расположенное по смещению
08h байт от начала атрибутного заголовка, равно нулю, то атрибут считается резидентным, а если единице, то атрибут нерезидентен. Любые другие значения недопустимы.

Первые четыре байта атрибутного заголовка определяют его тип. Тип атрибута, в свою очередь, определяет формат представления тела атрибута. В частности, тело атрибута данных (тип:
80h — $DATA) представляет собой «сырую» последовательность байт. Тело атрибута стандартной информации (тип:
10h —
$STANDARD_INFORMATION) описывает время его создания, права доступа и т. д.

Следующие четыре байта заголовка содержат длину атрибута, выражаемую в байтах. Длина нерезидентного атрибута равна сумме длин его тела и заголовка, а длина резидентного атрибута равна длине его заголовка. Если к смещению атрибута добавить его длину, мы получим указатель на следующий атрибут (или маркер конца, если текущий атрибут — последний в цепочке).

Длина тела резидентных атрибутов, выраженная в байтах, хранится в 32-разрядном поле, расположенном по смещению
10h байт от начала атрибутного заголовка. 16-разрядное поле, следующее за его концом, хранит смещение резидентного тела, отсчитываемое от начала атрибутного заголовка. С нерезидентными атрибутами в этом плане все намного сложнее, и для хранения длины их тела используется множество полей. Реальный размер тела атрибута (real size of attribute), выраженный в байтах, хранится в 64-разрядном поле, находящемся по смещению
30h байт от начала атрибутного заголовка. Следующее за ним 64-разрядное поле хранит инициализированный размер потока (initialized data size of the stream), выраженный в байтах. Судя по всему, инициализированный размер потока всегда равен реальному размеру тела атрибута. 64-разрядное поле, расположенное по смещению
28h байт от начала атрибутного заголовка, хранит выделенный размер (allocated size of attribute), выраженный в байтах и равный реальному размеру тела атрибута, округленному до размера кластера (в большую сторону).

Два 64-разрядных поля, расположенные по смещениям
10h и
18h байт от начала атрибутного заголовка, задают первый (starting VCN) и последний (last VCN) номера виртуального кластера, принадлежащего телу нерезидентного атрибута. Виртуальные кластеры представляют собой логические номера кластеров, не зависящие от своего физического расположения на диске. В подавляющем большинстве случаев номер первого кластера тела нерезидентного атрибута равен нулю, а последний — количеству кластеров, занятых телом атрибута, уменьшенному на единицу. 16-разрядное поле, расположенное по смещению
20h от начала атрибутного заголовка, содержит указатель на массив
Data Runs, расположенный внутри этого заголовка и описывающий логический порядок размещения нерезидентного тела атрибута на диске.

Каждый атрибут имеет свой собственный идентификатор (attribute ID), уникальный для данной файловой записи и хранящийся в 16-разрядном поле, расположенном по смещению
0Eh от начала атрибутного заголовка.

Если атрибут имеет имя (attribute Name), то 16-разрядное поле, расположенное по смещению
0Ah байт от атрибутного заголовка, содержит указатель на него. Для безымянных атрибутов оно равно нулю (большинство атрибутов имен не имеют). Имя атрибута хранится в атрибутном заголовке в формате Unicode, а его длина определяется 8-разрядным полем, расположенным по смещению
09h байт от начала атрибутного заголовка. Если тело атрибута сжато, зашифровано или разрежено, 16-разрядное поле флагов, расположенное по смещению
0Ch байт от начала атрибутного заголовка, не равно нулю.

Типы атрибутов

NTFS поддерживает большее количество предопределенных типов атрибутов. Тип атрибута определяет его назначение и формат представления тела. Полное описание всех атрибутов заняло бы целую книгу, поэтому кратко перечислю лишь наиболее «ходовые» из них. Так, атрибут стандартной информации
$STANDARD_INFORMATION описывает время создания, изменения и последнего доступа к файлу, права доступа, а также некоторую другую вспомогательную информацию (например, квоты).

Атрибут списка атрибутов (прямо каламбур)
$ATTRIBUTE_LIST используется в тех случаях, когда все атрибуты файла не умещаются в базовой файловой записи и файловая система вынуждена располагать их в расширенных файловых записях. Индексы расширенных файловых записей содержатся в атрибуте списка атрибутов, помещаемом в базовую файловую запись.

При каких обстоятельствах атрибуты не умещаются в одной файловой записи? Это может произойти в следующих случаях:

• файл содержит много альтернативных имен или жестких ссылок;
• файл сильно фрагментирован;
• файл содержит очень сложный дескриптор безопасности;
• файл имеет очень много потоков данных (т. е. атрибутов типа
  $DATA).

Атрибут полного имени файла
$FILE_NAME хранит имя файла в соответствующем пространстве имен. Таких атрибутов у файла может быть и несколько. Здесь же хранятся и жесткие ссылки (hard link), если они есть.

Списки отрезков

Тела нерезидентных атрибутов хранятся на диске в одной или нескольких кластерных цепочках, называемых отрезками (runs). Отрезком называется последовательность смежных кластеров, характеризующаяся номером начального кластера и длиной. Совокупность отрезков называется списком (run-list или data run).

Внутренний формат представления списков не то чтобы сложен, но простым его тоже не назовешь. Для экономии места длина отрезка и номер начального кластера хранятся в полях переменной длины. Если размер отрезка умещается в байт (т. е. его значение не превышает 255), то он займет один байт. По аналогии, если размер отрезка требует для своего представления двойного слова, то он займет двойное слово.

Сами же поля размеров хранятся в 4-битных ячейках, называемых нибблами (nibble) или полубайтами. Шестнадцатеричная система счисления позволяет легко переводить байты в нибблы и наоборот. Младший ниббл равен (
X & 15), а старший — (
X / 16). Иначе говоря, младший ниббл соответствует младшему шестнадцатеричному разряду байта, а старший — старшему. Например,
69h состоит из двух нибблов, причем младший равен
9h, а старший —
6h.

Список отрезков представляет собой массив структур, каждая из которых описывает характеристики «своего» отрезка. В конце списка находится завершающий ноль. Первый байт структуры состоит из двух нибблов: младший задает длину поля начального кластера отрезка (условно обозначаемого буквой
F), а старший — количество кластеров в отрезке (
L). Затем идет поле длины отрезка. В зависимости от значения
L оно может занимать от одного до восьми байт (поля большей длины недопустимы). Первый байт поля стартового кластера файла расположен по смещению
1 + L байт от начала структуры (что соответствует
2+2*L нибблам). Вот как выглядит структура одного элемента списка отрезков.

Начиная с версии 3.0 NTFS поддерживает разреженные (sparse) атрибуты, т. е. такие атрибуты, которые не записывают на диск кластеры, содержащие одни нули. При этом поле номера начального кластера отрезка может быть равным нулю, что означает, что данному отрезку не выделен никакой кластер. Поле длины содержит количество кластеров, заполненных нулями.

Назначение служебных файлов

NTFS содержит большое количество служебных файлов (метафайлов) строго определенного формата. Важнейший из метафайлов,
$MFT, мы только что рассмотрели. Остальные метафайлы играют вспомогательную роль. Тем не менее если они окажутся искажены, то штатный драйвер файловой системы не сможет работать с таким томом, поэтому иметь некоторые представления о назначении каждого из них все же необходимо.

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

Назначение основных метафайлов NTFS

Заключение

Мы рассмотрели общую структуру NTFS версии 3.1, которая используется начиная с Windows XP и заканчивая Windows Server 2019, включая, конечно же, Windows 10. Эта информация поможет тебе лучше понять, как Windows хранит файлы, а также может пригодиться в процессе восстановления поврежденных данных. Конечно же, подробное описание архитектуры NTFS может занять отдельную и весьма объемную книгу (которых, кстати, существует немало), но за подробностями ты всегда можешь обратиться к технической документации.

(4 оценок, среднее: 4,50 из 5)

Загрузка…

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

Часть 1. Физическая структура NTFS

Начнем с общих фактов. Раздел NTFS, теоретически, может быть почти какого угодно размера. Предел, конечно, есть, но я даже не буду указывать его, так как его с запасом хватит на последующие сто лет развития вычислительной техники — при любых темпах роста. Как обстоит с этим дело на практике? Почти так же. Максимальный размер раздела NTFS в данный момент ограничен лишь размерами жестких дисков. NT4, правда, будет испытывать проблемы при попытке установки на раздел, если хоть какая-нибудь его часть отступает более чем на 8 Гб от физического начала диска, но эта проблема касается лишь загрузочного раздела.

Лирическое отступление. Метод инсталляции NT4.0 на пустой диск довольно оригинален и может навести на неправильные мысли о возможностях NTFS. Если вы укажете программе установки, что желаете отформатировать диск в NTFS, максимальный размер, который она вам предложит, будет всего 4 Гб. Почему так мало, если размер раздела NTFS на самом деле практически неограничен? Дело в том, что установочная секция просто не знает этой файловой системы Программа установки форматирует этот диск в обычный FAT, максимальный размер которого в NT составляет 4 Гбайт (с использованием не совсем стандартного огромного кластера 64 Кбайта), и на этот FAT устанавливает NT. А вот уже в процессе первой загрузки самой операционной системы (еще в установочной фазе) производится быстрое преобразование раздела в NTFS; так что пользователь ничего и не замечает, кроме странного «ограничения» на размер NTFS при установке.

Структура раздела — общий взгляд

Как и любая другая система, NTFS делит все полезное место на кластеры — блоки данных, используемые единовременно. NTFS поддерживает почти любые размеры кластеров — от 512 байт до 64 Кбайт, неким стандартом же считается кластер размером 4 Кбайт. Никаких аномалий кластерной структуры NTFS не имеет, поэтому на эту, в общем-то, довольно банальную тему, сказать особо нечего.

Диск NTFS условно делится на две части. Первые 12% диска отводятся под так называемую MFT зону — пространство, в которое растет метафайл MFT (об этом ниже). Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой — это делается для того, чтобы самый главный, служебный файл (MFT) не фрагментировался при своем росте. Остальные 88% диска представляют собой обычное пространство для хранения файлов.

Свободное место диска, однако, включает в себя всё физически свободное место — незаполненные куски MFT-зоны туда тоже включаются. Механизм использования MFT-зоны таков: когда файлы уже нельзя записывать в обычное пространство, MFT-зона просто сокращается (в текущих версиях операционных систем ровно в два раза), освобождая таким образом место для записи файлов. При освобождении места в обычной области MFT зона может снова расширится. При этом не исключена ситуация, когда в этой зоне остались и обычные файлы: никакой аномалии тут нет. Что ж, система старалась оставить её свободной, но ничего не получилось. Жизнь продолжается… Метафайл MFT все-таки может фрагментироваться, хоть это и было бы нежелательно.

MFT и его структура

Файловая система NTFS представляет собой выдающееся достижение структуризации: каждый элемент системы представляет собой файл — даже служебная информация. Самый главный файл на NTFS называется MFT, или Master File Table — общая таблица файлов. Именно он размещается в MFT зоне и представляет собой централизованный каталог всех остальных файлов диска, и, как не парадоксально, себя самого. MFT поделен на записи фиксированного размера (обычно 1 Кбайт), и каждая запись соответствует какому либо файлу (в общем смысле этого слова). Первые 16 файлов носят служебный характер и недоступны операционной системе — они называются метафайлами, причем самый первый метафайл — сам MFT. Эти первые 16 элементов MFT — единственная часть диска, имеющая фиксированное положение. Интересно, что вторая копия первых трех записей, для надежности — они очень важны — хранится ровно посередине диска. Остальной MFT-файл может располагаться, как и любой другой файл, в произвольных местах диска — восстановить его положение можно с помощью его самого, «зацепившись» за самую основу — за первый элемент MFT.

Метафайлы

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

Метафайлы находятся корневом каталоге NTFS диска — они начинаются с символа имени «$», хотя получить какую-либо информацию о них стандартными средствами сложно. Любопытно, что и для этих файлов указан вполне реальный размер — можно узнать, например, сколько операционная система тратит на каталогизацию всего вашего диска, посмотрев размер файла $MFT. В следующей таблице приведены используемые в данный момент метафайлы и их назначение.

Файлы и потоки

Итак, у системы есть файлы — и ничего кроме файлов. Что включает в себя это понятие на NTFS?

• Прежде всего, обязательный элемент — запись в MFT, ведь, как было сказано ранее, все файлы диска упоминаются в MFT. В этом месте хранится вся информация о файле, за исключением собственно данных. Имя файла, размер, положение на диске отдельных фрагментов, и т. д. Если для информации не хватает одной записи MFT, то используются несколько, причем не обязательно подряд.
• Опциональный элемент — потоки данных файла. Может показаться странным определение «опциональный», но, тем не менее, ничего странного тут нет. Во-первых, файл может не иметь данных — в таком случае на него не расходуется свободное место самого диска. Во-вторых, файл может иметь не очень большой размер. Тогда идет в ход довольно удачное решение: данные файла хранятся прямо в MFT, в оставшемся от основных данных месте в пределах одной записи MFT. Файлы, занимающие сотни байт, обычно не имеют своего «физического» воплощения в основной файловой области — все данные такого файла хранятся в одном месте — в MFT.

Довольно интересно обстоит дело и с данными файла. Каждый файл на NTFS, в общем-то, имеет несколько абстрактное строение — у него нет как таковых данных, а есть потоки (streams). Один из потоков и носит привычный нам смысл — данные файла. Но большинство атрибутов файла — тоже потоки! Таким образом, получается, что базовая сущность у файла только одна — номер в MFT, а всё остальное опционально. Данная абстракция может использоваться для создания довольно удобных вещей — например, файлу можно «прилепить» еще один поток, записав в него любые данные — например, информацию об авторе и содержании файла, как это сделано в Windows 2000 (самая правая закладка в свойствах файла, просматриваемых из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами: наблюдаемый размер файла — это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длинны, при стирании которого освободится 1 Гбайт свободного места — просто потому, что какая-нибудь хитрая программа или технология прилепила в нему дополнительный поток (альтернативные данные) гигабайтового размера. Но на самом деле в текущий момент потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны. Просто имейте в виду, что файл на NTFS — это более глубокое и глобальное понятие, чем можно себе вообразить просто просматривая каталоги диска. Ну и напоследок: имя файла может содержать любые символы, включая полый набор национальных алфавитов, так как данные представлены в Unicode — 16-битном представлении, которое дает 65535 разных символов. Максимальная длина имени файла — 255 символов.

Каталоги

Каталог на NTFS представляет собой специфический файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение данных на диске. Файл каталога поделен на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент MFT, который уже предоставляет полную информацию об элементе каталога. Внутренняя структура каталога представляет собой бинарное дерево. Вот что это означает: для поиска файла с данным именем в линейном каталоге, таком, например, как у FAT-а, операционной системе приходится просматривать все элементы каталога, пока она не найдет нужный. Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся более быстрым способом — с помощью получения двухзначных ответов на вопросы о положении файла. Вопрос, на который бинарное дерево способно дать ответ, таков: в какой группе, относительно данного элемента, находится искомое имя — выше или ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает зону поиска в среднем в два раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на вопрос осуществляется очевидным способом — сравнением начальных букв. Область поиска, суженная в два раза, начинает исследоваться аналогичным образом, начиная опять же со среднего элемента.

Вывод — для поиска одного файла среди 1000, например, FAT придется осуществить в среднем 500 сравнений (наиболее вероятно, что файл будет найден на середине поиска), а системе на основе дерева — всего около 12-ти (2^10 = 1024). Экономия времени поиска налицо. Не стоит, однако думать, что в традиционных системах (FAT) всё так запущено: во-первых, поддержание списка файлов в виде бинарного дерева довольно трудоемко, а во-вторых — даже FAT в исполнении современной системы (Windows2000 или Windows98) использует сходную оптимизацию поиска. Это просто еще один факт в вашу копилку знаний. Хочется также развеять распространенное заблуждение (которое я сам разделял совсем еще недавно) о том, что добавлять файл в каталог в виде дерева труднее, чем в линейный каталог: это достаточно сравнимые по времени операции — дело в том, что для того, чтобы добавить файл в каталог, нужно сначала убедится, что файла с таким именем там еще нет — и вот тут-то в линейной системе у нас будут трудности с поиском файла, описанные выше, которые с лихвой компенсируют саму простоту добавления файла в каталог.

Какую информацию можно получить, просто прочитав файл каталога? Ровно то, что выдает команда dir. Для выполнения простейшей навигации по диску не нужно лазить в MFT за каждым файлом, надо лишь читать самую общую информацию о файлах из файлов каталогов. Главный каталог диска — корневой — ничем не отличается об обычных каталогов, кроме специальной ссылки на него из начала метафайла MFT.

Журналирование

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

Пример 1: осуществляется запись данных на диск. Вдруг выясняется, что в то место, куда мы только что решили записать очередную порцию данных, писать не удалось — физическое повреждение поверхности. Поведение NTFS в этом случае довольно логично: транзакция записи откатывается целиком — система осознает, что запись не произведена. Место помечается как сбойное, а данные записываются в другое место — начинается новая транзакция.

Пример 2: более сложный случай — идет запись данных на диск. Вдруг, бах — отключается питание и система перезагружается. На какой фазе остановилась запись, где есть данные, а где чушь? На помощь приходит другой механизм системы — журнал транзакций. Дело в том, что система, осознав свое желание писать на диск, пометила в метафайле $LogFile это свое состояние. При перезагрузке это файл изучается на предмет наличия незавершенных транзакций, которые были прерваны аварией и результат которых непредсказуем — все эти транзакции отменяются: место, в которое осуществлялась запись, помечается снова как свободное, индексы и элементы MFT приводятся в с состояние, в котором они были до сбоя, и система в целом остается стабильна. Ну а если ошибка произошла при записи в журнал? Тоже ничего страшного: транзакция либо еще и не начиналась (идет только попытка записать намерения её произвести), либо уже закончилась — то есть идет попытка записать, что транзакция на самом деле уже выполнена. В последнем случае при следующей загрузке система сама вполне разберется, что на самом деле всё и так записано корректно, и не обратит внимания на «незаконченную» транзакцию.

И все-таки помните, что журналирование — не абсолютная панацея, а лишь средство существенно сократить число ошибок и сбоев системы. Вряд ли рядовой пользователь NTFS хоть когда-нибудь заметит ошибку системы или вынужден будет запускать chkdsk — опыт показывает, что NTFS восстанавливается в полностью корректное состояние даже при сбоях в очень загруженные дисковой активностью моменты. Вы можете даже оптимизировать диск и в самый разгар этого процесса нажать reset — вероятность потерь данных даже в этом случае будет очень низка. Важно понимать, однако, что система восстановления NTFS гарантирует корректность файловой системы, а не ваших данных. Если вы производили запись на диск и получили аварию — ваши данные могут и не записаться. Чудес не бывает.

Сжатие

Файлы NTFS имеют один довольно полезный атрибут — «сжатый». Дело в том, что NTFS имеет встроенную поддержку сжатия дисков — то, для чего раньше приходилось использовать Stacker или DoubleSpace. Любой файл или каталог в индивидуальном порядке может хранится на диске в сжатом виде — этот процесс совершенно прозрачен для приложений. Сжатие файлов имеет очень высокую скорость и только одно большое отрицательное свойство — огромная виртуальная фрагментация сжатых файлов, которая, правда, никому особо не мешает. Сжатие осуществляется блоками по 16 кластеров и использует так называемые «виртуальные кластеры» — опять же предельно гибкое решение, позволяющее добиться интересных эффектов — например, половина файла может быть сжата, а половина — нет. Это достигается благодаря тому, что хранение информации о компрессированности определенных фрагментов очень похоже на обычную фрагментацию файлов: например, типичная запись физической раскладки для реального, несжатого, файла:

кластеры файла с 1 по 43-й хранятся в кластерах диска начиная с 400-го

кластеры файла с 44 по 52-й хранятся в кластерах диска начиная с 8530-го…

Физическая раскладка типичного сжатого файла:

кластеры файла с 1 по 9-й хранятся в кластерах диска начиная с 400-го

кластеры файла с 10 по 16-й нигде не хранятся

кластеры файла с 17 по 18-й хранятся в кластерах диска начиная с 409-го

кластеры файла с 19 по 36-й нигде не хранятся

Видно, что сжатый файл имеет «виртуальные» кластеры, реальной информации в которых нет. Как только система видит такие виртуальные кластеры, она тут же понимает, что данные предыдущего блока, кратного 16-ти, должны быть разжаты, а получившиеся данные как раз заполнят виртуальные кластеры — вот, по сути, и весь алгоритм.

Безопасность

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

Права файловой системы NTFS неразрывно связаны с самой системой — то есть они, вообще говоря, необязательны к соблюдению другой системой, если ей дать физический доступ к диску. Для предотвращения физического доступа в Windows2000 (NT5) всё же ввели стандартную возможность — об этом см. ниже. Система прав в своем текущем состоянии достаточно сложна, и я сомневаюсь, что смогу сказать широкому читателю что-нибудь интересное и полезное ему в обычной жизни. Если вас интересует эта тема — вы найдете множество книг по сетевой архитектуре NT, в которых это описано более чем подробно.

На этом описание строение файловой системы можно закончить, осталось описать лишь некоторое количество просто практичных или оригинальных вещей.

Hard Links

Эта штука была в NTFS с незапамятных времен, но использовалась очень редко — и тем не менее: Hard Link — это когда один и тот же файл имеет два имени (несколько указателей файла-каталога или разных каталогов указывают на одну и ту же MFT запись). Допустим, один и тот же файл имеет имена 1.txt и 2.txt: если пользователь сотрет файл 1, останется файл 2. Если сотрет 2 — останется файл 1, то есть оба имени, с момента создания, совершенно равноправны. Файл физически стирается лишь тогда, когда будет удалено его последнее имя.

Symbolic Links (NT5)

Гораздо более практичная возможность, позволяющая делать виртуальные каталоги — ровно так же, как и виртуальные диски командой subst в DOSе. Применения достаточно разнообразны: во-первых, упрощение системы каталогов. Если вам не нравится каталог Documents and settingsAdministratorDocuments, вы можете прилинковать его в корневой каталог — система будет по прежнему общаться с каталогом с дремучим путем, а вы — с гораздо более коротким именем, полностью ему эквивалентным. Для создания таких связей можно воспользоваться программой junction (junction.zip, 15 Кб), которую написал известный специалист Mark Russinovich. Программа работает только в NT5 (Windows 2000), как и сама возможность.

Для удаления связи можно воспользоваться стандартной командой rd.
ВНИМАНИЕ: Попытка уделения связи с помощью проводника или других файловых менеджеров, не понимающих виртуальную природу каталога (например, FAR), приведет к удалению данных, на которые ссылается ссылка! Будьте осторожны.

Шифрование (NT5)

Полезная возможность для людей, которые беспокоятся за свои секреты — каждый файл или каталог может также быть зашифрован, что не даст возможность прочесть его другой инсталляцией NT. В сочетании со стандартным и практически непрошибаемым паролем на загрузку самой системы, эта возможность обеспечивает достаточную для большинства применений безопасность избранных вами важных данных.Часть 2. Особенности дефрагментации NTFS

Вернемся к одному достаточно интересному и важному моменту — фрагментации и дефрагментации NTFS. Дело в том, что ситуация, сложившаяся с этими двумя понятиями в настоящий момент, никак не может быть названа удовлетворительной. В самом начале утверждалось, что NTFS не подвержена фрагментации файлов. Это оказалось не совсем так, и утверждение сменили — NTFS препятствует фрагментации. Оказалось, что и это не совсем так. То есть она, конечно, препятствует, но толк от этого близок к нулю… Сейчас уже понятно, что NTFS — система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. Единственное что — логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации — лишних движений головок — она, конечно, не спасает. И поэтому — вперед и с песней.

К истокам проблемы

Как известно, система сильнее всего фрагментирует файлы когда свободное место кончается, когда приходится использовать мелкие дырки, оставшиеся от других файлов. Тут возникает первое свойство NTFS, которое прямо способствует серьезной фрагментации.

Диск NTFS поделен на две зоны. В начала диска идет MFT зона — зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется — зона сокращается ровно в два раза :). И так далее. Таким образом мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% — фрагментация растет как бешенная.

Попутное следствие — диск, заполненный более чем на 88%, дефрагментировать почти невозможно — даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра.

Далее. NTFS работает себе и работает, и всё таки фрагментируется — даже в том случае, если свободное место далеко от истощения. Этому способствует странный алгоритм нахождения свободного места для записи файлов — второе серьезное упущение. Алгоритм действий при любой записи такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):

16 — 16 — 16 — 16 — 16 — [скачек назад] — 15 — 15 — 15 — [назад] — 14 — 14 — 14 …. 1 — 1 — 1 -1 — 1…

Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более большие куски свободного места.

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

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

Средства решения?

В NT существует стандартное API дефрагментации. Обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:

1. В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это неинтересные в данный момент тонкости).
2. Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) «временно занятое место», дополняющее его по размеру до кратности 16 кластерам.
3. При попытке как-то неправильно (»не кратно 16») переместить файл результат часто непредсказуем. Что-то округляется, что-то просто не перемещается… Тем не менее, всё место действия щедро рассыпается «временно занятым местом».

«Временно занятое место» служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то пол минуты.

Тем не менее, логично было бы использовать это API, раз он есть. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, состоит из следующих фаз (не обязательно в этом порядке):

• Вынимание файлов из MFT зоны. Не специально — просто обратно туда их положить не представляется возможным Безобидная фаза, и даже в чем то полезная.
• Дефрагментация файлов. Безусловно, полезный процесс, несколько, правда, осложняемый ограничениями кратности перемещений — файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
• Дефрагментация MFT, виртуалки (pagefile.sys) и каталогов. Возможна через API только в Windows2000, иначе — при перезагрузке, отдельным процессом, как в старом Diskeeper-е.
• Складывание файлов ближе к началу — так называемая дефрагментация свободного места. Вот это — воистину страшный процесс.

Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий — после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером. Которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации — одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров… Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так — желательно каждую неделю. Бред? Реальность.

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

Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую — Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными — Diskeeper, O&O defrag, т. д. — не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk — единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 Кбайт, а SpeedDisk и это может.

К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно, плодит дырки <16 кластеров. Так что как только появится (если еще не появился) — так сразу надо качать Speeddisk для W2k.

Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз — нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложились исторически.Часть 3. Что выбрать?

Любая из представленных ныне файловых систем уходит своими корнями в глубокое прошлое — еще к 80-м годам. Да, NTFS, как это не странно — очень старая система! Дело в том, что долгое время персональные компьютеры пользовались лишь операционной системой DOS, которой и обязана своим появлением FAT. Но параллельно разрабатывались и тихо существовали системы, нацеленные на будущее. Две таких системы, получившие всё же широкое признание — NTFS, созданная для операционной системы Windows NT 3.1 еще в незапамятные времена, и HPFS — верная спутница OS/2.

Внедрение новых систем шло трудно — еще в 95м году, с выходом Windows95, ни у кого не было и мыслей о том, что что-то нужно менять — FAT получил второе дыхание посредством налепленной сверху заплатки «длинные имена», реализация которых там хоть и близка к идеально возможной без изменения системы, но всё же довольно бестолкова. Но в последующие годы необходимость перемен назрела окончательно, поскольку естественные ограничения FAT стали давать о себе знать. FAT32, появившаяся в Windows 95 OSR2, просто сдвинула рамки — не изменив сути системы, которая просто не дает возможности организовать эффективную работу с большим количеством данных.

HPFS (High Performance File System), активно применяемая до сих пор пользователями OS/2, показала себя достаточно удачной системой, но и она имела существенные недостатки — полное отсутствие средств автоматической восстанавливаемости, излишнюю сложность организации данных и невысокую гибкость.

NTFS же долго не могла завоевать персональные компьютеры из-за того, что для организации эффективной работы с её структурами данных требовались значительные объемы памяти. Системы с 4 или 8 Мбайт (стандарт 95-96 годов) были просто неспособны получить хоть какой-либо плюс от NTFS, поэтому за ней закрепилась не очень правильная репутация медленной и громоздкой системы. На самом деле это не соответствует действительности — современные компьютерные системы с памятью более 64 Мб получают просто огромный прирост производительности от использования NTFS.

В данной таблице сведены воедино все существенные плюсы и минусы распространенных в наше время систем, таких как FAT32, FAT и NTFS. Вряд ли разумно обсуждать другие системы, так как в настоящее время 97% пользователей делают выбор между Windows98, Windows NT4.0 и Windows 2000 (NT5.0), а других вариантов там просто нет.

Хотелось бы выразить искреннюю признательность Андрею Шабалину, без которого эта статья просто не была бы написана, а даже будучи написанной, содержала бы много досадных неточностей

Продолжение читайте в статье «Надежность дисковой системы NT»

Файловая
система NTFS была разработана в качестве
основной файловой системы для ОС Windows
NT в начале 90-х гг. прошлого столетия с
учетом опыта разработки файловых систем
FAT и HPFS (основная файловая система
для OS/2), а также других существовавших
в то время файловых систем и является
последней разработкой компании Microsoft
в области файловых систем.

Структура тома
NTFS

Как
и файловой системе FAT
файлы в NTFS
записываются в виде последовательности
кластеров. Кластеры в файловой системе
NTFS
могут принимать размеры от 512 байт до
64 Кбт. Стандартным значением длины
кластера является размер 4 Кбт.

В
отличие от разделов FAT все пространство
тома (логического раздела) NTFS представляет
собой либо файл, либо часть файла. Основой
структуры тома NTFS является MFT (Master File
Table) – главная таблица файлов, которая
содержит, по крайней мере, одну запись
для каждого файла тома, включая одну
запись для самой себя, т.е. представляет
собой каталог всех имеющихся файлов,
причем файлы небольшого размера (менее
1500 байт) хранятся прямо в MFT – это заметно
ускоряет доступ к ним.

Первые
12% диска под управлением NTFS отводятся
под так называемую MFT зону – пространство,
в которое растет метафайл MFT. Запись
каких-либо данных в эту область невозможна.
Остальные 88% диска представляют собой
обычное пространство для хранения
файлов.

Все
файлы на томе NTFS идентифицируются
номером файла, который определяется
позицией файла в MFT.

Весь
том NTFS состоит из последовательности
кластеров, что отличает эту файловую
систему от рассмотренных ранее, где на
кластеры делилась только область данных.
Порядковый номер кластера в томе NTFS
называется логическим номером кластера
(Logical Cluster Number, LCN). Файл NTFS также состоит
из после­дова­тель­ности кластеров,
при этом порядковый номер кластера
внутри файла называется виртуальным
номером кластера (Virtual Cluster Number, VCN).

Базовая
единица распределения дискового
пространства для файловой системы NTFS
– непрерывная область кластеров,
называемая отрезком. В качестве адреса
отрезка NTFS использует логический номер
его первого кластера, а также количество
кластеров в отрезке k, т. е. пара (LCN,
k). Таким образом, часть файла, помещенная
в отрезок и начинающаяся с виртуального
кластера VCN, характеризуется адресом,
состоящим из трех чисел: (VCN, LCN, k).

Для
хранения номера кластера в NTFS используются
64-разрядные указатели, что дает возможность
поддерживать тома и файлы размером до
2⁶⁴
кластеров. При размере кластера в 4 Кбт
это позволяет использовать тома и файлы,
практически неограниченного размера.

Структура
тома NTFS показана на рис. 4.7. Загрузочный
блок тома NTFS располагается в начале
тома, а его копия – в середине тома.
Загрузочный блок содержит стандартный
блок параметров BIOS, количество блоков
в томе, а также начальный логический
номер кластера основной копии MFT и
зеркальной копии MFT.

Далее
располагается первый отрезок MFT, который
поделен на записи фиксированного размера
(около 1 Кбайт), и каждая запись
соответствует какому-либо файлу. Для
работы файловой системы очень важны
первые 16 файлов MFT (указатели на системные
файлы) – они называются метафайлами, и
их
имена начинаются с символа «$»,
причем самый первый метафайл – сам MFT.

Рис.
4.7. Структура тома NTFS

Эти первые
16 файлов MFT – единственная часть диска,
имеющая фиксированное положение. Вторая
копия первых трех записей для надежности
хранится ровно посередине диска.
В результате «снести» NTFS довольно
непросто: система в состоянии обойти
серьезные неисправности поверхности
диска и пережить даже повреждение
MFT (аналогичная ситуация для FAT закончилась
бы фатально).

Остальной
MFT-файл может располагаться, как и любой
другой файл, в произвольных местах диска
– восстановить его положение можно с
помощью его самого, «зацепившись» за
самую основу – за первый элемент MFT. В
табл. 4.1 представлен список метафайлов
файловой системы NTFS.

Таблица 4.1

В
NTFS файл целиком размещается в записи
таблицы MFT, если это позволяет сделать
его размер. В том же случае, когда размер
файла больше размера записи MFT, в запись
помещаются только некоторые атрибуты
файла, а остальная часть файла размещается
в отдельном отрезке тома (или нескольких
отрезках). Часть файла, размещаемая в
записи MFT, называется резидентной частью,
а остальные части – нерезидентными.
Адресная информация об отрезках,
содержащих нерезидентные части файла,
размещается в атрибутах резидентной
части.

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

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

Структура файлов
NTFS

Понятие
файла для NTFS включает в себя:

– обязательный
элемент – запись в MFT. В этом месте
хранится вся информация
о файле, за исключением собственно
данных – имя файла, размер, положение
на диске отдельных фрагментов, и т.д.
Если для информации
не хватает одной записи MFT, то используются
несколько, причем не обязательно подряд;

– опциональный
элемент – потоки данных файла.

NTFS
просматривает каждый файл (или каталог)
как набор атрибутов файла. Такие элементы,
как имя файла, информация зашиты и даже
данные – все это атрибуты файла. Каждый
атрибут идентифицирован кодом типа
атрибута и необязательно именем атрибута,
т. е. в трактовке NTFS кроме атрибутов у
файла нет никаких других компонентов.

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

Таким образом,
базовая сущность у файла только одна –
номер в MFT, а все остальное опционально,
т.е. файл на NTFS – это более глубокое и
глобальное понятие, чем то, что мы видим,
просто просматривая каталоги диска.

Хотя
одна из причин появления множественных
потоков данных в NTFS
весьма тривиальна – при работе ПК
Macintosh
и PC
с одним и тем же сервером необходимо,
чтобы файловая система сервера
поддерживала формат файлов клиента, а
в файловой системе Macintosh
файл может иметь два потока (forks):
поток данных и поток ресурсов. Почему
потоков в NTFS
стало много – вопрос к разработчикам.

Каждый
атрибут файла NTFS состоит из полей: тип
атрибута; длина атрибута; значение
атрибута и, возможно, имя атрибута. Тип
атрибута, длина и имя образуют заголовок
атрибута.

Имеется
системный набор атрибутов, определяемых
структурой тома NTFS. Системные атрибуты
имеют фиксированные имена и коды их
типа, а также определенный формат. Могут
применяться также атрибуты, определяемые
пользователями. Их имена, типы и форматы
задаются исключительно пользователем.
Атрибуты файлов упорядочены по убыванию
кода атрибута, причем атрибут одного и
того же типа может повторяться несколько
раз.

Существуют
два способа хранения атрибутов файла
– резидентное хранение в записях таблицы
MFT и нерезидентное хранение вне ее, во
внешних отрезках. Таким образом,
резидентная часть файла состоит из
резидентных атрибутов, а нерезидентная
– из нерезидентных атрибутов. Сортировка
может осуществляться только по резидентным
атрибутам.

Системный набор
включает следующие атрибуты:

– Attribute
List (список атрибутов) – список атрибутов,
из которых состоит файл; содержит ссылки
на номер записи MFT, где расположен каждый
атрибут; этот редко используемый атрибут
нужен только в том случае, если атрибуты
файла не умещаются в основной записи и
занимают дополнительные записи MFT;

– File
Name (имя файла) – этот атрибут содержит
длинное имя файла в формате Unicode, а также
номер входа в таблице MFT для родительского
каталога; если этот файл содержится
в нескольких каталогах, то у него
будет несколько атрибутов типа File Name;
этот атрибут всегда должен быть
резидентным;

– MS-DOS Name (имя
MS-DOS) – этот атрибут содержит имя файла
в формате 8.3;

– Version (версия)
– атрибут содержит номер последней
версии файла;

– Security
Descriptor (дескриптор безопасности) – этот
атрибут содержит информацию о защите
файла: список прав доступа ACL и поле
аудита, которое определяет, какого рода
операции над этим файлом нужно
регистрировать;

– Volume
Version (версия тома) – версия тома,
используется только в системных файлах
тома;

– Volume Name (имя
тома) – имя тома;

– Data
(данные) – содержит обычные данные
файла;

– MFT
bitmap (битовая карта MFT) – этот атрибут
содержит карту использования блоков
на томе;

– Index
Root (корень индекса) – корень бинарного
дерева, используемого для поиска файлов
в каталоге;

– Index
Allocation (размещение индекса) – нерезидентные
части индексного списка бинарного
дерева;

– Standard
Information (стандартная информация) – этот
атрибут хранит всю остальную стандартную
информацию о файле, которую трудно
связать с каким-либо из других атрибутов
файла, например, время создания файла,
время обновления и другие.

Если
файл NTFS имеет небольшой размер, то он
может целиком располагаться внутри
одной записи MFT, имеющей, например, размер
2 Кбайт. Небольшие файлы NTFS состоят по
крайней мере из следующих атрибутов
(рис 4.8):

– стандартная
информация
(SI – standard information);

– имя
файла
(FN – file name);

– данные
(Data);

– дескриптор
безопасности
(SD – security descriptor).

И

Рис.
4.8. Небольшой файл NTFS

з-за того что файл может
иметь переменное количество атрибутов,
а также из-за переменного размера
атрибутов нельзя точно утверждать, что
файл уместится внутри записи. Однако
обычно файлы размером менее 1500 байт
помещаются внутри записи MFT (размером
2 Кбайта).

Если
данные файла не помещаются в одну запись
МFТ,
то этот факт отражается в заголовке
атрибута Data, который содержит признак
того, что этот атрибут является
нерезидентным, т. е. находится в
отрезках вне таблицы MFT. В этом случае
атрибут Data содержит адресную информацию
(LCN, VCN, k) каждого отрезка данных.

Если
же файл настолько велик, что его атрибут
данных, хранящий адреса нерезидентных
отрезков данных, не помещается в одной
записи, то этот атрибут помещается в
другую запись MFT, а ссылка на такой
атрибут помещается в основную запись
файла. Эта ссылка содержится в атрибуте
Attribute List. Сам атрибут данных по-прежнему
содержит адреса нерезидентных отрезков
данных.

Для
сверхбольших файлов в атрибуте Attribute
List могут указываться несколько атрибутов,
расположенных в дополнительных записях
MFT. Кроме того, может использоваться
двойная косвенная адресация, когда
нерезидентный атрибут будет ссылаться
на другие нерезидентные атрибуты,
поэтому в NTFS не может быть файлов слишком
большой для системы длины.

Каталоги NTFS

Каталог
на NTFS представляет собой специфический
файл, хранящий ссылки на другие файлы
и каталоги, создавая иерархическое
строение данных на диске. Файл каталога
поделен на блоки, каждый из которых
содержит имя файла, базовые атрибуты и
ссылку на элемент MFT, который уже
предоставляет полную информацию об
элементе каталога.

Если
каталог не слишком велик, то, как и в
случае с файлом, он помещается в записи
MFT.

Для
больших каталогов используется другой
формат хранения. Внутренняя структура
каталога представляет собой бинарное
дерево. Это означает, что для поиска
файла с данным именем в линейном каталоге
операционной системе приходится
просматривать все элементы каталога,
пока она не найдет нужный. Бинарное же
дерево располагает имена файлов таким
образом, чтобы поиск файла осуществлялся
более быстрым способом – с помощью
получения двухзначных ответов на вопросы
о положении файла. Вопрос, на который
бинарное дерево способно дать ответ,
таков: в какой группе, относительно
данного элемента, находится искомое
имя – выше или ниже? Опрос начинается
со среднего элемента, и каждый ответ
сужает зону поиска в среднем в два раза.
Файлы отсортированы по алфавиту, и ответ
на вопрос осуществляется сравнением
начальных букв. Область поиска, суженная
в два раза, начинает исследоваться
аналогичным образом, начиная опять же
со среднего элемента (рис. 4.9).

Такой
поиск методом половинного разбиения
дает в сравнении с методом линейного
поиска (поиска перебором) значительную
экономию времени поиска. Например, для
поиска одного файла среди 1000 FAT придется
осуществить в среднем 500 сравнений
(наиболее вероятно, что файл будет найден
на середине поиска), а системе на основе
дерева – всего около 12-ти (2¹⁰ = 1024).
Экономия времени поиска налицо. Стоит,
однако, заметить, что в традиционной
FAT (Windows 2000 или Wind

Рис. 4.9. Принцип
поиска файлов в каталоге

ows 98) используется сходная
система оптимизации поиска.

Какую
информацию можно получить, просто
прочитав файл каталога? Ту, что выдает
команда просмотра каталога. Для выполнения
простейшей навигации по диску не нужно
обращаться в MFT за каждым файлом, надо
лишь читать самую общую информацию о
файлах из файлов каталогов. Главный
каталог диска – корневой – ничем не
отличается от обычных каталогов, кроме
специальной ссылки на него из начала
метафайла MFT.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #