Изначально в NTFS была заложена способность индексации любых атрибутов, значительно сокращающая время поиска файла по заданному списку критериев (например, времени последнего доступа). Индексы хранятся в виде двоичных деревьев, поэтому среднее время выполнения запроса оценивается как O(lg n). На практике в существующих драйверах NTFS реализована индексация лишь по имени файла. Как уже говорилось ранее, каталог представляет собой файл особого типа — файл индексов. В отличие от FAT, где файл каталога представляет собой единственный источник данных об организации файлов, в NTFS файл каталога используется лишь для ускорения доступа к содержимому каталога. Он не является обязательным, так как ссылка на родительский каталог всякого файла в обязательном порядке присутствует в атрибуте его имени (
$FILE_NAME
).
Каждый атрибут может быть зашифрован, разрежен или сжат. Техника работы с такими атрибутами выходит далеко за рамки первичного знакомства с организацией файловой системы и будет рассмотрена позднее. Пока же рассмотрим углубленно фундамент файловой системы NTFS — структуру
$MFT
.
Главная файловая таблица
В процессе форматирования логического раздела в его начале создается так называемая зона MFT (рис. 6.2). По умолчанию она занимает 12,5% от емкости тома (а не 12%, как утверждается во многих публикациях), хотя, в зависимости от значения параметра
NtfsMftZoneReservation
, она может составлять 25%, 37% или 50%.
Рис. 6.2. Структура тома, отформатированного под NTFS
В этой области расположен файл
$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, а также подробное описание принципов ее работы, можно найти на сайте Марка Руссиновича (http://www.sysinternals.com). Но, как бы там ни было, заполнять том более чем на 88% его емкости категорически не рекомендуется!
При необходимости файл
$MFT
может быть перемещен в любую часть диска, и тогда в начале тома его уже не окажется. Стартовый адрес файла
$MFT
хранится в загрузочном секторе по смещению
30h
байт от его начала (
см. описание структуры загрузочного сектора в гл. 5). В подавляющем большинстве случаев этот адрес ссылается на четвертый кластер.
Файл
$MFT
представляет собой массив записей типа
<i>FILE Record</i>
(в терминологии UNIX они называются
inodes), каждая из которых описывает соответствующий ей файл или подкаталог. На практике один файл или подкаталог полностью описывается единственной записью типа
FILE Record
, хотя в теории этих записей может потребоваться и несколько.
Для ссылки на одну файловую запись из другой используется ее порядковый номер (он же индекс) в файле
$MFT
, отсчитываемый от нуля.
Файловая ссылка (file reference) состоит из двух частей (см. табл. 6.2) — 48-битного
индекса и 16-битного
номера последовательности (sequence number).
Таблица 6.2. Структура файловой ссылки
| Смещение | Размер (байт) | Описание |
00h
| 6 | Индекс файловой записи ( FILE
record number), отсчитываемый от нуля |
06h
| 2 | Номер последовательности (sequence number) |
При удалении файла или каталога соответствующая ему файловая последовательность помечается как неиспользуемая. При создании новых файлов записи, помеченные как неиспользуемые, могут задействоваться вновь, при этом счетчик номера последовательности, хранящийся внутри файловой записи, увеличивается на единицу. Этот механизм позволяет отслеживать "мертвые" ссылки на уже удаленные файлы. Номер последовательности внутри файловой ссылки в этом случае будет отличаться от номера последовательности соответствующей файловой записи. Этой проверкой занимается утилита chkdsk, но автоматически она, насколько мне известно, не выполняется.
Первые 12 записей в MFT всегда занимают служебные метафайлы:
$MFT
(собственно, сам файл
$MFT
),
$MFTMirr
(зеркало
$MFT
),
$LogFile
(файл транзакций),
$Volume
(сведения о дисковом томе),
$AttrDef
(определения атрибутов),
'.'
(корневой каталог),
$Bitmap
(карта свободного пространства),
$Boot
(системный загрузчик),
$BadClus
(перечень плохих кластеров) и т.д. Более подробно эти записи описаны в табл. 6.11.
Первые четыре записи настолько важны, что продублированы в специальном файле
$MFTMirr
, находящемся примерно в середине тома (точный адрес этого файла хранится в загрузочном секторе по смещению
38h
байт от его начала). Вопреки своему названию, файл
$MFTMirr
— это отнюдь не "зеркало" всего файла
$MFT
, а всего лишь резервная копия первых четырех его элементов.
