ntfs mft extents что это

NTFS изнутри. Как устроена файловая таблица MFT в Windows

Содержание статьи

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

NTFS с высоты птичьего полета

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

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

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Крис Касперски

Известный российский хакер. Легенда ][, ex-редактор ВЗЛОМа. Также известен под псевдонимами мыщъх, nezumi (яп. 鼠, мышь), n2k, elraton, souriz, tikus, muss, farah, jardon, KPNC.

Источник

Восстановление поврежденных разделов NTFS

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

Программы же восстановления NTFS от сторонних производителей, к сожалению, труднодоступны и дороги. Ситуация усугубляется отсутствием полной документации по низкоуровневой структуре управляющих блоков NTFS.

Что же делать, если в один прекрасный момент обнаруживается, что компьютер с ОС Windows NT больше не загружается или некоторые логические разделы NTFS стали вдруг недоступны?

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

Проблемы с диском

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

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

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

Поэтому если сломался жесткий диск с ценной информацией, приготовьтесь пожертвовать еще одним для ремонта и найдите третий для копирования восстановленных данных.

Если есть подозрение на неисправность контроллера диска, попробуйте его заменить. Проверьте также соединительный кабель.

Проблемы с файловой системой

Убедившись, что диск, контроллер и соединительный кабель исправны, не торопитесь использовать дискету NT Repair Disk, созданную при установке ОС, или запускать программу восстановления файловой системы chkdsk — результат может оказаться плачевным. Не пытайтесь также найти «волшебную» программу восстановления NTFS в комплекте Norton Utilities для Windows NT — пока ее там нет. Если информация, записанная на диске, имеет особую ценность, нужно вначале проанализировать состояние управляющих блоков файловой системы NTFS с помощью редактора диска.

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

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

Сначала подключается только первый диск и инсталлируется ОС Windows NT. Этот диск будет использован для сохранения файлов, восстановленных из разделов поврежденного. Далее устанавливается редактор Disk Probe, входящий в состав Windows NT Resource Kit. Хотя этот редактор далек от совершенства, именно он позволит выполнить всю работу по восстановлению потерянных файлов.

Убедившись, что с первым диском все в порядке, выключите компьютер и подключите к нему второй, поврежденный диск.

Определение геометрии логического устройства

Для успешного восстановления информации следует определить размер кластера и адрес загрузочного сектора. Первое значение можно получить из загрузочного сектора раздела NTFS (если, конечно, его содержимое сохранилось).

Запустите программу Disk Probe. Выберите в меню Drive позицию Physical Drive. В панели Open Physical Drive, появившейся на экране, укажите устройство PhysicalDrive1, дважды щелкнув левой клавишей мыши по соответствующей строке списка Available Physical Drives. Затем нажмите кнопку Set Active, оставив включенным переключатель Read Only, и закройте панель кнопкой OK (рис. 1).

Рис. 1. Выбор физического диска

В результате программа Disk Probe получит доступ на чтение поврежденного диска. После этого попытайтесь прочитать содержимое главной загрузочной записи диска, расположенной в первом секторе на нулевой дорожке нулевого цилиндра. Для этого в меню Sectors выберите строку Read. Появится панель Read Sector. В поле Starting Sector укажите номер первого сектора, равный нулю, а в поле Numbers of Sectors установите значение 1. Затем нажмите кнопку Read.

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

Добравшись до загрузочной записи нужного вам раздела, выберите из меню View строку NTFS Bootsector. Вы должны увидеть что-то вроде изображения на рис. 2.

Рис. 2. Просмотр загрузочного сектора раздела NTFS

Здесь содержатся все сведения о геометрии восстанавливаемого раздела. В частности, размер кластера в секторах находится в поле Sectors per cluster. Кроме того, здесь приведены номера кластеров основной и резервной таблицы MFT (поля Clusters to MFT и Clusters to MFT mirr соответственно).

А что делать, если главная загрузочная запись или загрузочная запись нужного раздела уничтожены?

Эта ситуация тяжелая, но не фатальная. Подробную таблицу соответствия емкости логического устройства NTFS и числа кластеров можно найти в MSDN. Например, если емкость находится в интервале 1025 — 2048 Мбайт, размер кластера будет равен 4 секторам, а если в диапазоне от 8193 до 16 384 Мбайт — то в одном кластере будет 32 сектора. Заметим, однако, что, позаботившись заранее о возможности последующего восстановления диска в случае его повреждения, можно облегчить такую работу, когда в ней возникнет необходимость. Нужно определить и записать размер кластера сразу после установки ОС, пока загрузочный сектор NTFS еще цел.

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

Таблица MFT

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

Файловая система FAT (и ее разновидность FAT32) хранит информацию о файлах в нескольких местах логического устройства. Дескриптор файла, содержащий его имя, размер, дату создания и номер первого выделенного для него кластера, находится в каталоге. Таблица размещения файлов File Allocation Table, от которой и произошло название файловой системы FAT, хранит связанный список всех кластеров, выделенных файлу. И наконец, сам файл может быть распылен по кластерам.

Такая организация в значительной мере затрудняет восстановление файлов в случае каких-либо сбоев. Особенно критичной является целостность таблицы FAT: если эта таблица пропала или ее содержимое оказалось частично разрушено, исчезает информация о кластерах, выделенных файлу. В результате файл можно с очень большим трудом собрать из отдельных кластеров, лишь зная его содержимое. К тому же эта работа требует очень много времени. Поэтому на практике исчезновение таблицы FAT и ее копии означает полную потерю файлов.

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

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

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

Как найти таблицу MFT?

Найти таблицу MFT достаточно просто, если сохранился загрузочный сектор раздела NTFS. Нажмите кнопку Go около поля Clusters to MFT или Clusters to MFT mirr в панели, показанной на рис. 2. Для просмотра содержимого первого сектора таблицы выберите из меню View программы Disk Probe строку Bytes. Результат выполнения такой операции показан на рис. 3.

Рис. 3. Содержимое первого сектора таблицы MFT

Обратите внимание на строку FILE, расположенную в самом начале сектора. С нее начинаются записи таблицы, описывающие файлы. Существуют еще записи для каталогов, элементов индекса и другие, которые мы не будем рассматривать.

Рис. 4. Поиск начала таблицы MFT

Если загрузочный сектор разрушен, начало таблицы MFT нетрудно найти с помощью программы Disk Probe. Для этого выберите в меню Tools строку Search Sector, установите переключатели в положение, показанное на рис. 4, и, заполнив поле Enter characters to search for, нажмите кнопку Search. Следует запастись терпением, поскольку процесс поиска может отнять немало времени.

Заметим, что подобным образом можно найти в таблице MFT записи для тех файлов, которые нужно восстановить. Так как имена файлов хранятся в кодировке Unicode, при поиске следует установить переключатель в положение Unicode characters. Кроме того, необходимо включить режим поиска Exhaustive search и Ignore case.

Анализ записей MFT

К сожалению, программа Disk Probe не содержит никаких средств для форматного просмотра содержимого записей MFT. Более того, точный формат этой записи отсутствует в открытой документации Microsoft. Однако многое можно обнаружить в Internet, сделав запрос по ключевым словам «NTFS Documentation». Нам, например, удалось найти информацию, собранную разработчиками модулей для операционной системы Linux. Анализируя исходные тексты модуля для монтирования в Linux файловой системы NTFS, можно понять назначение отдельных полей записей MFT (авторы приносят благодарность Максиму Синеву за помощь в «расшифровке» записей MFT).

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

Первые четыре байта в записи, описывающей файл, образуют слово FILE. На рис. 3 они выделены красным цветом. Следующие два байта (выделенные синим цветом) — смещение так называемой области Fixup. В рассматриваемом случае значение смещения равно 002A (с учетом обратного порядка расположения байтов в слове). Здесь и далее будем пользоваться шестнадцатеричными числами.

Область Fixup используется в процессе обнаружения ошибок чтения или записи. Она состоит из слов размером два байта. Количество слов хранится в записи MFT со смещением 0006. На рис. 3 поле размера области Fixup выделено фиолетовым цветом. Там хранится значение 0003, следовательно, область Fixup начинается со смещения 002A и простирается до 002A+(2*0003)=002F.

Сразу за областью Fixup начинаются поля атрибутов. Смещение первого атрибута равно 0030.

Первые четыре байта области атрибутов определяют тип, а следующие четыре — размер в байтах. Например, вслед за областью Fixup со смещением 0030 следует атрибут с типом 10. На рис. 3 тип этого и следующего за ним атрибутов выделен красным цветом (размер атрибута выделен синим). Атрибут занимает 48 байт, следовательно, следующий атрибут (с типом 30) начнется со смещением 0078.

Таким образом можно выделить в записи MFT все атрибуты. В конце самого последнего записано значение FFFFFFFF — признак конца цепочки атрибутов.

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

Рис. 5. Атрибут данных

Как видно из рисунка, тип атрибута, равный 80, хранится в записи MFT со смещением 0160. Всего атрибут данных занимает D8 байт, так как именно это значение находится в четырехбайтовом поле со смещением 4 относительно начала атрибута.

Байт со смещением 8 относительно начала атрибута данных — это признак резидентного размещения файла. Если его значение равно 1, запись MFT хранит только список кластеров, выделенных файлу (как в описываемом случае), а если 0 — файл находится внутри самой записи MFT. Как правило, записи содержат только файлы небольших размеров.

Для того чтобы определить точное расположение нерезидентного файла на диске, нужно проследить цепочку так называемых блоков виртуальных номеров кластеров Virtual Cluster Number (VCN), или просто блоков VCN. Показатель смещения начала этой цепочки хранится в двухбайтовом поле, имеющем смещение 20 байт относительно начала атрибута данных. В описываемом случае этот показатель равен 40, а смещение области блоков VCN относительно начала записи MFT равно 01A0. На рис. 5 эта область выделена жирной вертикальной линией зеленого цвета.

Анализ области блоков VCN

Файл, записанный в разделе NTFS, может быть сегментирован. Он состоит из одного или нескольких фрагментов, называемых экстентами. Размер и расположение каждого экстента описывается в блоке VCN. В зависимости от того, фрагментирован файл или нет, область VCN может содержать один блок или их набор. Блоки VCN имеют переменный размер, определяемый первым байтом.

Формат блока стоит показать на конкретном примере. Возьмем первый блок VCN, имеющий в рассматриваемом примере смещение 01A0 относительно начала записи MFT:

Второй блок VCN расположен сразу вслед за первым:

Для того чтобы определить первый кластер второго экстента, необходимо прибавить к адресу первого экстента смещение, указанное во втором блоке VCN (с учетом знака). В данном случае второй экстент размещен в кластере с номером 0286D9+21=286FA. Длина второго экстента составляет 0824 кластера.

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

Резидентные файлы

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

Рис. 6. Запись таблицы MFT с резидентным атрибутом

При этом смещение резидентных данных, т. е. файла, записано в двухбайтовом слове со смещением 14 относительно начала атрибута данных, а размер — в двухбайтовом слове со смещением 10.

Приведем небольшой пример. Для иллюстрации формата записи MFT, содержащей резидентный атрибут данных, мы подготовили маленький файл с именем Small.txt, содержащий текстовую строку «This is a small text file.». Затем с помощью программы Disk Probe мы обнаружили запись таблицы MFT, созданную для этого файла (рис. 6).

Здесь атрибут данных начинается со смещением 0160 относительно начала записи MFT. Байт со смещением 8 внутри этого атрибута (выделен зеленым цветом) равен нулю, следовательно, мы имеем дело с резидентным атрибутом.

Как видно из рис. 6, байты файла Small.txt (выделенные желтым цветом) находятся внутри записи MFT со смещением 18 относительно начала атрибута данных, а размер файла составляет 1A байт.

Как же восстановить файлы?

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

Когда известны имена файлов, подлежащих восстановлению, нужно найти соответствующие им записи в таблице MFT. Это можно сделать с помощью программы Disk Probe, воспользовавшись строкой Search Sector из меню Tools. Далее следует обнаружить в этой записи атрибут данных и определить, резидентный он или нет.

Если атрибут данных резидентный, то нужно сохранить сектор, содержащий запись MFT, в виде файла на исправном жестком диске или на дискете. Это можно сделать, используя строку Save as меню File программы Disk Probe. После этого следует вырезать нужную часть данных и сохранить результат в новом файле. Такую операцию нетрудно выполнить, например, в редакторе Norton Disk Editor для MS-DOS.

В случае нерезидентного атрибута работы будет намного больше.

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

Восстановив все экстенты, объедините их в один файл (например, командой COPY с параметром /B). Затем установите правильную длину файла, полученную из поля со смещением 30 атрибута данных. В разделе FAT такая операция может быть выполнена с помощью все той же программы Norton Disk Editor.

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

Что же касается полностью автоматических средств, восстанавливающих разрушенные разделы NTFS и случайно удаленные файлы, до здесь можно упомянуть программу Tiramisu for Windows NT, разработанную в компании OnTrack Data International, Inc. Ее бесплатная демонстрационная версия доступна по адресу http://www. recovery.de.

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

Мы все-таки рекомендуем использовать автоматические средства только в крайнем случае, особенно если речь идет о восстановлении особо важных данных. Известно, например, что такая программа, как Norton Disk Doctor, может в некоторых случаях не только не улучшить, но даже ухудшить состояние диска FAT, сделав потерю данных невозвратимой.

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

Источник

Файловая система NTFS

Операционные системы Microsoft семейства Windows NT нельзя представить без файловой системы NTFS — одной из самых сложных и удачных из существующих на данный момент файловых систем. Данная статья расскажет вам, в чем особенности и недостатки этой системы, на каких принципах основана организация информации, и как поддерживать систему в стабильном состоянии, какие возможности предлагает 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, в общем-то, имеет несколько абстрактное строение — у него нет как таковых данных, а есть потоки (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 в этом случае довольно логично: транзакция записи откатывается целиком — система осознает, что запись не произведена. Место помечается как сбойное, а данные записываются в другое место — начинается новая транзакция.

И все-таки помните, что журналирование — не абсолютная панацея, а лишь средство существенно сократить число ошибок и сбоев системы. Вряд ли рядовой пользователь 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 выглядит так (размеры фрагментов):

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

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

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

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

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

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

Источник