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

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

Операционные системы 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 диска - они начинаются с символа имени "$", хотя получить какую-либо информацию о них стандартными средствами сложно. Любопытно, что и  для этих файлов указан вполне реальный размер - можно узнать, например, сколько  операционная система тратит на каталогизацию  всего вашего диска, посмотрев размер файла   

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

Итак, у системы  есть файлы - и ничего кроме файлов. Что включает в себя это понятие  на 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 гарантирует  корректность файловой системы, а не ваших данных. Если вы производили  запись на диск и получили аварию - ваши данные могут и не записаться. Чудес  не бывает.