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

    Каждый файл на NTFS имеет несколько абстрактное строение - у него нет как таковых данных, а есть потоки (streams). Один из потоков и носит привычный нам смысл - данные файла. Но большинство атрибутов файла - тоже потоки! Таким образом, получается, что базовая сущность у файла только одна - номер в MFT, а всё остальное опционально. Данная абстракция может использоваться для создания довольно удобных вещей - например, файлу можно \"прилепить\" еще один поток, записав в него любые данные - например, информацию об авторе и содержании файла, как это сделано в Windows 2000 (самая правая закладка в свойствах файла, просматриваемых из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами: наблюдаемый размер файла - это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длины, при стирании которого освободится 1 Гбайт свободного места - просто потому, что какая-нибудь хитрая программа или технология прилепила в нему дополнительный поток (альтернативные данные) гигабайтового размера. Но на самом деле в текущий момент потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны.  

    Каталоги

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

    Вывод - для поиска одного файла среди 1000, например, FAT придется осуществить в  среднем 500 сравнений (наиболее вероятно, что файл будет найден на середине поиска), а системе на основе дерева - всего около 12-ти (2^10 = 1024). Экономия времени поиска налицо. Не стоит, однако думать, что в традиционных системах (FAT) всё так запущено: во-первых, поддержание  списка файлов в виде бинарного дерева довольно трудоемко, а во-вторых - даже FAT в исполнении современной системы (Windows2000 или Windows98) использует сходную  оптимизацию поиска. Это просто еще  один факт в вашу копилку знаний. Хочется также развеять распространенное заблуждение (которое я сам разделял совсем еще недавно) о том, что  добавлять файл в каталог в  виде дерева труднее, чем в линейный каталог: это достаточно сравнимые  по времени операции - дело в том, что для того, чтобы добавить файл в каталог, нужно сначала убедится, что файла с таким именем там  еще нет :) - и вот тут-то в линейной системе у нас будут трудности  с поиском файла, описанные выше, которые с лихвой компенсируют саму простоту добавления файла в каталог.

    Какую информацию можно получить, просто прочитав файл каталога? Ровно то, что  выдает команда dir. Для выполнения простейшей навигации по диску не нужно лазить в MFT за каждым файлом, надо лишь читать самую общую информацию о файлах из файлов каталогов. Главный каталог  диска - корневой - ничем не отличается об обычных каталогов, кроме специальной  ссылки на него из начала метафайла MFT.  

5. Атрибуты  файла NTFS

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

     Если  атрибуты файла могут находится внутри записи файла MFT, они называются резидентными (resident) атрибутами. HanpHMqi, информация типа имени файла и отметки времени всегда включается в запись файла MFT. Если файл слишком большой, чтобы содержать все атрибуты в записи файла MFT, часть атрибутов является нерезидентной (nonresident). Нерезидентные атрибуты занимают один или несколько пробегов (run) дискового пространства в другом месте тома (пробег дискового пространства — непрерывная линейная область на диске).

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

     В табл. 1 представлен список всех атрибутов  файла, в настоящее время определенных для NTFS. Этот список расширяем, т. е. другие атрибуты файла в будущем могут  быть определены в случае необходимости. 

     Таблица 1. Атрибуты файла NTFS

6. Системные файлы NTFS

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

     Таблица 2. Системные файлы NTFS

3. Конфиденциальность  и сохранность  данных

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

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

    Однако  главное достоинство NTFS - журналирование и методы, которыми файловая система  проводит операции с данными. Любое  действие в разделе NTFS выполняется  транзакцией. Транзакция - это пакет  операций, который или выполняется  полностью или не выполняется  совсем, третьего не дано. Любое действие с данными записывается в журнал; из него в случае какого-либо сбоя в  дальнейшем можно узнать, какая транзакция не смогла успешно завершиться и  почему. Основные объекты NTFS ко всему  прочему зеркалируются, т. е. делается резервная копия загрузочной  записи и некоторых элементов MFT. Такая логика операций с данными  приводит к высокой стабильности файловой системы. Сбой во время дефрагментации, скорее всего, будет просто незаметен  для пользователя, в то время как  для FAT32 такая ошибка стала бы в  большинстве случаев фатальной.

1. Журналирование NTFS

    Прежде  всего, мне хотелось бы рассказать о  том, какие именно операции журналируются. Совершенно очевидно, что полный undo-файл, способный откатить абсолютно все  операции, абсолютно невозможен как  с точки зрения быстродействия, так  и с точки зрения здравого смысла. Да, такое журналирование дало бы возможность  восстановить большее число данных - например, при осуществлении перезаписи трех мегабайт в середине файла мы могли бы сначала сохранить новые  данные в логе, затем переписать туда же предыдущие три мегабайта  файла, и уж только затем осуществлять операции с реальными данными. Такой  подход гарантировал бы полную определенность с судьбой информации - мы всегда смогли бы понять, какая часть данных уже записалась на диск, а какая  находится в исходном, не обновленном  состоянии. Он имеет всего один скромный недостаток - небольшая накладочка по быстродействию: для записи на диск трех мегабайт мы вынуждены будем  осуществить разнообразные дисковые операции на объем в три раза больший - девять мегабайт. Да, полное журналирование также применяется - но в основном при работе с базами данных. Если вы желаете обеспечить полное журналирование каких-либо данных, вы можете поставить MS SQL или даже Oracle, который вообще не будет пользоваться средствами какой  либо файловой системы и обеспечит  сохранность ваших данных в любых  разумных условиях.

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

1. Отложенная  запись и контрольные точки журналирования

    Известно, что любая современная система  для ускорения файловых операций вынуждена использовать кэширование, в том числе - кэширование операций записи. Так называемая отложенная запись - принцип кэширования, при  котором данные, предназначенные  для записи на диск, некоторое время  сохраняются в КЭШе и лишь в  свободное от других занятий время  сохраняются физически. Отложенная запись существенно повышает эффективность  дисковых операций, так как такое  кэширование группирует множество  операций в одну - это особенно эффективно, если запись производится в компактные участки диска. Еще один плюс отложенной записи - не мешать более нужным операциям  чтения, и осуществлять запись только тогда, когда система свободна и  ей не требуется доступ к диску  для других нужд. Как согласовать  отложенную запись с журналированием? Это довольно сложный вопрос, так  как откладывание записи делает возможным  потерю тех данных, которые находились в очереди на физическую запись и  не успели записаться на диск до сбоя. Самое неприятное здесь даже не потеря данных, а то, что происходит рассогласование  времени записи: какие-то служебные  области могут быть обновлены, а  какие-то смежные по смыслу - еще  нет, так как их обновление могло  отложится еще на пару секунд и  не состоятся из-за сбоя.

    NTFS справляется с этими проблемами  с помощью смысловой интеграции  операций отложенной записи и  ведения журнала. При попытке  начать журналируемую операцию  в лог тут же записывается  намерение - например, стереть файл. Это случается без задержек - на  этом этапе отложенная запись  не работает: это плата за присутствие  журналирования, которой нельзя избежать. Но вот все остальные операции уже идут в задержанном режиме - то есть они могут состояться частично или не состоятся вообще. Единственная задержанная операция, работа которой несколько отличается от простой записи - запись в лог об удачном завершении предыдущих транзакций, так называемая контрольная точка. Через определенные промежутки времени - обычно через каждые несколько секунд - система в обязательном порядке сбрасывает абсолютно все задержанные операции на диск. После произведения этой операции в журнал записывается простейшая запись - контрольная точка, - которая говорит о том, что все предыдущие операции выполнены корректно на всех уровнях - как на логическом, так и на физическом.