Назначение атрибута определяется его типом (type) – четырехбайтовым шестнадцатеричным значением. При желании атрибуту можно дать еще и имя (name), состоящее из символов, входящих в соответствующее пространство имен. Подавляющее большинство файлов имеет по меньшей мере три атрибута: стандартная информация о файле (время создания, модификации последнего доступа, права доступа и т. д.) хранится в атрибуте типа 10h, условно обозначаемом $STANDARD_INFORMATION. Ранние версии Windows NT позволяли обращаться к атрибутам по их условным обозначениям, однако Windows 2000 и Windows XP лишены этой возможности. Полное имя файла (не путать с путем!) хранится в атрибуте типа 30h ($FILE_NAME). Если у файла есть одно или более альтернативных имен (например, MS-DOS-имя), таких атрибутов может быть несколько. Здесь же хранится ссылка (file reference) на материнский каталог, позволяющая разобраться, к какому каталогу данный файл/подкаталог принадлежит. Данные файла по умолчанию хранятся в безымянном атрибуте типа 80h ($DATA), однако при желании прикладные приложения могут создавать дополнительные потоки данных, отделяя имя атрибута от имени файла знаком двоеточия, например:

ECHO xxx > file:attr1; ECHO yyy > file:attr2; more < file:attr1; more  < file:attr2

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

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

Главная файловая запись (master file table)

В процессе форматирования логического раздела, в его начале создается так называемая MTF-зона (MFT-zone), по умолчанию занимающая 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-драйвер, это в принципе позволяет! Подробности (вместе с самой утилитой дефрагментации) можно найти на сайте Марка Руссиновича. Но, как бы то ни было, заполнять дисковый том более чем на 88% его емкости категорически не рекомендуется!

При необходимости $MFT-файл может быть перемещен в любую часть диска, и тогда в начале тома его уже не окажется. Стартовый адрес $MFT-файла хранится в Boot-секторе по смещению 30h байт от его начала (см. «boot-сектор», описанный в предыдущей статье данного цикла) и в подавляющем большинстве случаев этот адрес ссылается на 4-й кластер.