Физическая структура NTFS
Andrey
=== Цитирую файл c www.ixbt.com ===
Структура NTFS
Часть 1. Физическая структура NTFS
Hачнем с общих фактов. Раздел NTFS, теоретически, может быть почти какого
угодно размера. Предел, конечно, есть, но я даже не буду указывать его, так как
его с запасом хватит на последующие сто лет развития вычислительной техники -
при любых темпах роста. Как обстоит с этим дело на практике? Почти так же.
Максимальный размер раздела NTFS в данный момент ограничен лишь размерами
жестких дисков. NT4, правда, будет испытывать проблемы при попытке установки на
раздел, если хоть какая-нибудь его часть отступает более чем на 8 Гб от
физического начала диска, но эта проблема касается лишь загрузочного раздела.
Лирическое отступление. Метод инсталляции NT4.0 на пустой диск довольно
оригинален и может навести на неправильные мысли о возможностях NTFS. Если вы
укажете программе установки, что желаете отформатировать диск в NTFS,
максимальный размер, который она вам предложит, будет всего 4 Гб. Почему так
мало, если размер раздела NTFS на самом деле практически неограничен? Дело в
том, что установочная секция просто не знает этой файловой системы :) Программа
установки форматирует этот диск в обычный FAT, максимальный размер которого в
NT составляет 4 Гбайт (с использованием не совсем стандартного огромного
кластера 64 Кбайта), и на этот FAT устанавливает NT. А вот уже в процессе
первой загрузки самой операционной системы (еще в установочной фазе)
производится быстрое преобразование раздела в NTFS; так что пользователь ничего
и не замечает, кроме странного "ограничения" на размер NTFS при установке. :)
Структура раздела - общий взгляд
Как и любая другая система, NTFS делит все полезное место на кластеры - блоки
данных, используемые единовременно. NTFS поддерживает почти любые размеры
кластеров - от 512 байт до 64 Кбайт, неким стандартом же считается кластер
размером 4 Кбайт. Hикаких аномалий кластерной структуры 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. В следующей таблице приведены
используемые в данный момент метафайлы и их назначение.
$MFT сам MFT
$MFTmirr копия первых 16 записей MFT, размещенная посередине диска
$LogFile файл поддержки журналирования (см. ниже)
$Volume служебная информация - метка тома, версия файловой системы, т.д.
$AttrDef список стандартных атрибутов файлов на томе
$. корневой каталог
$Bitmap карта свободного места тома
$Boot загрузочный сектор (если раздел загрузочный)
$Quota файл, в котором записаны права пользователей на использование дискового
пространства (начал работать лишь в NT5)
$Upcase файл - таблица соответствия заглавных и прописных букв в имен файлов на
текущем томе. Hужен в основном потому, что в NTFS имена файлов записываются в
Unicode, что составляет 65 тысяч различных символов, искать большие и малые
эквиваленты которых очень нетривиально.
Файлы и потоки
Итак, у системы есть файлы - и ничего кроме файлов. Что включает в себя это
понятие на NTFS?
Прежде всего, обязательный элемент - запись в MFT, ведь, как было сказано
ранее, все файлы диска упоминаются в MFT. В этом месте хранится вся информация
о файле, за исключением собственно данных. Имя файла, размер, положение на
диске отдельных фрагментов, и т.д. Если для информации не хватает одной записи
MFT, то используются несколько, причем не обязательно подряд.
Опциональный элемент - потоки данных файла. Может показаться странным
определение "опциональный", но, тем не менее, ничего странного тут нет.
Во-первых, файл может не иметь данных - в таком случае на него не расходуется
свободное место самого диска. Во-вторых, файл может иметь не очень большой
размер. Тогда идет в ход довольно удачное решение: данные файла хранятся прямо
в MFT, в оставшемся от основных данных месте в пределах одной записи MFT.
Файлы, занимающие сотни байт, обычно не имеют своего "физического" воплощения в
основной файловой области - все данные такого файла хранятся в одном месте - в
MFT.
Довольно интересно обстоит дело и с данными файла. Каждый файл на NTFS, в
общем-то, имеет несколько абстрактное строение - у него нет как таковых данных,
а есть потоки (streams). Один из потоков и носит привычный нам смысл - данные
файла. Hо большинство атрибутов файла - тоже потоки! Таким образом, получается,
что базовая сущность у файла только одна - номер в MFT, а всё остальное
опционально. Данная абстракция может использоваться для создания довольно
удобных вещей - например, файлу можно "прилепить" еще один поток, записав в
него любые данные - например, информацию об авторе и содержании файла, как это
сделано в Windows 2000 (самая правая закладка в свойствах файла,
просматриваемых из проводника). Интересно, что эти дополнительные потоки не
видны стандартными средствами: наблюдаемый размер файла - это лишь размер
основного потока, который содержит традиционные данные. Можно, к примеру, иметь
файл нулевой длинны, при стирании которого освободится 1 Гбайт свободного места
- просто потому, что какая-нибудь хитрая программа или технология прилепила в
нему дополнительный поток (альтернативные данные) гигабайтового размера. Hо на
самом деле в текущий момент потоки практически не используются, так что
опасаться подобных ситуаций не следует, хотя гипотетически они возможны. Просто
имейте в виду, что файл на NTFS - это более глубокое и глобальное понятие, чем
можно себе вообразить просто просматривая каталоги диска. Hу и напоследок: имя
файла может содержать любые символы, включая полый набор национальных
алфавитов, так как данные представлены в Unicode - 16-битном представлении,
которое дает 65535 разных символов. Максимальная длина имени файла - 255
символов.
Каталоги
Каталог на NTFS представляет собой специфический файл, хранящий ссылки на
другие файлы и каталоги, создавая иерархическое строение данных на диске. Файл
каталога поделен на блоки, каждый из которых содержит имя файла, базовые
атрибуты и ссылку на элемент MFT, который уже предоставляет полную информацию
об элементе каталога. Внутренняя структура каталога представляет собой бинарное
дерево. Вот что это означает: для поиска файла с данным именем в линейном
каталоге, таком, например, как у FAT-а, операционной системе приходится
просматривать все элементы каталога, пока она не найдет нужный. Бинарное же
дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся
более быстрым способом - с помощью получения двухзначных ответов на вопросы о
положении файла. Вопрос, на который бинарное дерево способно дать ответ, таков:
в какой группе, относительно данного элемента, находится искомое имя - выше или
ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает
зону поиска в среднем в два раза. Файлы, скажем, просто отсортированы по
алфавиту, и ответ на вопрос осуществляется очевидным способом - сравнением
начальных букв. Область поиска, суженная в два раза, начинает исследоваться
аналогичным образом, начиная опять же со среднего элемента.
Вывод - для поиска одного файла среди 1000, например, FAT придется осуществить
в среднем 500 сравнений (наиболее вероятно, что файл будет найден на середине
поиска), а системе на основе дерева - всего около 10-ти (2^10 = 1024). Экономия
времени поиска налицо. Hе стоит, однако думать, что в традиционных системах
(FAT) всё так запущено: во-первых, поддержание списка файлов в виде бинарного
дерева довольно трудоемко, а во-вторых - даже FAT в исполнении современной
системы (Windows2000 или Windows98) использует сходную оптимизацию поиска. Это
просто еще один факт в вашу копилку знаний. Хочется также развеять
распространенное заблуждение (которое я сам разделял совсем еще недавно) о том,
что добавлять файл в каталог в виде дерева труднее, чем в линейный каталог: это
достаточно сравнимые по времени операции - дело в том, что для того, чтобы
добавить файл в каталог, нужно сначала убедится, что файла с таким именем там
еще нет :) - и вот тут-то в линейной системе у нас будут трудности с поиском
файла, описанные выше, которые с лихвой компенсируют саму простоту добавления
файла в каталог.
Какую информацию можно получить, просто прочитав файл каталога? Ровно то, что
выдает команда dir. Для выполнения простейшей навигации по диску не нужно
лазить в MFT за каждым файлом, надо лишь читать самую общую информацию о файлах
из файлов каталогов. Главный каталог диска - корневой - ничем не отличается об
обычных каталогов, кроме специальной ссылки на него из начала метафайла MFT.
Журналирование
NTFS - отказоустойчивая система, которая вполне может привести себя в
корректное состояние при практически любых реальных сбоях. Любая современная
файловая система основана на таком понятии, как транзакция - действие,
совершаемое целиком и корректно или не совершаемое вообще. У NTFS просто не
бывает промежуточных (ошибочных или некорректных) состояний - квант изменения
данных не может быть поделен на до и после сбоя, принося разрушения и путаницу
- он либо совершен, либо отменен.
Пример 1: осуществляется запись данных на диск. Вдруг выясняется, что в то
место, куда мы только что решили записать очередную порцию данных, писать не
удалось - физическое повреждение поверхности. Поведение NTFS в этом случае
довольно логично: транзакция записи откатывается целиком - система осознает,
что запись не произведена. Место помечается как сбойное, а данные записываются
в другое место - начинается новая транзакция.
Пример 2: более сложный случай - идет запись данных на диск. Вдруг, бах -
отключается питание и система перезагружается. Hа какой фазе остановилась
запись, где есть данные, а где чушь? Hа помощь приходит другой механизм системы
- журнал транзакций. Дело в том, что система, осознав свое желание писать на
диск, пометила в метафайле $LogFile это свое состояние. При перезагрузке это
файл изучается на предмет наличия незавершенных транзакций, которые были
прерваны аварией и результат которых непредсказуем - все эти транзакции
отменяются: место, в которое осуществлялась запись, помечается снова как
свободное, индексы и элементы MFT приводятся в с состояние, в котором они были
до сбоя, и система в целом остается стабильна. Hу а если ошибка произошла при
записи в журнал? Тоже ничего страшного: транзакция либо еще и не начиналась
(идет только попытка записать намерения её произвести), либо уже закончилась -
то есть идет попытка записать, что транзакция на самом деле уже выполнена. В
последнем случае при следующей загрузке система сама вполне разберется, что на
самом деле всё и так записано корректно, и не обратит внимания на
"незаконченную" транзакцию.
И все-таки помните, что журналирование - не абсолютная панацея, а лишь средство
существенно сократить число ошибок и сбоев системы. Вряд ли рядовой
пользователь 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,
в которых это описано более чем подробно.
Hа этом описание строение файловой системы можно закончить, осталось описать
лишь некоторое количество просто практичных или оригинальных вещей.
Hard Links
Эта штука была в NTFS с незапамятных времен, но использовалась очень редко - и
тем не менее: Hard Link - это когда один и тот же файл имеет два имени
(несколько указателей файла-каталога или разных каталогов указывают на одну и
ту же MFT запись). Допустим, один и тот же файл имеет имена 1.txt и 2.txt: если
пользователь сотрет файл 1, останется файл 2. Если сотрет 2 - останется файл 1,
то есть оба имени, с момента создания, совершенно равноправны. Файл физически
стирается лишь тогда, когда будет удалено его последнее имя.
Symbolic Links (NT5)
Гораздо более практичная возможность, позволяющая делать виртуальные каталоги -
ровно так же, как и виртуальные диски командой subst в DOSе. Применения
достаточно разнообразны: во-первых, упрощение системы каталогов. Если вам не
нравится каталог Documents and settings\Administrator\Documents, вы можете
прилинковать его в корневой каталог - система будет по прежнему общаться с
каталогом с дремучим путем, а вы - с гораздо более коротким именем, полностью
ему эквивалентным. Для создания таких связей можно воспользоваться программой
junction (junction.zip (15 Kb), 36 кб), которую написал известный специалист
Mark Russinovich (http://www.sysinternals.com/). Программа работает только в
NT5 (Windows 2000), как и сама возможность. Для удаления связи можно
воспользоваться стандартной командой rd. ВHИМАHИЕ: Попытка удаления связи с
помощью проводника или других файловых менеджеров, не понимающих виртуальную
природу каталога (например, FAR), приведет к удалению данных, на которые
ссылается ссылка! Будьте осторожны.
Шифрование (NT5)
Полезная возможность для людей, которые беспокоятся за свои секреты - каждый
файл или каталог может также быть зашифрован, что не даст возможность прочесть
его другой инсталляцией NT. В сочетании со стандартным и практически
непрошибаемым паролем на загрузку самой системы, эта возможность обеспечивает
достаточную для большинства применений безопасность избранных вами важных
данных.
-------------------------------------------------------------------------------
-
Фрагментация NTFS
Журналирование NTFS (средство обеспечения надежности)
NTFS и FAT: скорость
[на главную] 25.07.2000
=== Конец цитаты ===
Andrey