Примерно все это выглядит так:
Свободное место диска, однако, включает в себя всё физически свободное
место - незаполненные куски MFT-зоны туда тоже включаются. Механизм
использования MFT-зоны таков: когда файлы уже нельзя записывать в
обычное пространство, MFT-зона просто сокращается (в текущих версиях
операционных систем ровно в два раза), освобождая, таким образом, место
для записи файлов. При освобождении места в обычной области MFT зона
может снова расширится. При этом не исключена ситуация, когда в этой
зоне остались и обычные файлы: никакой аномалии тут нет. Система
старалась оставить её свободной, но ничего не получилось. Не смотря на
все эти меры по предотвращению фрагментации, метафайл MFT все-таки может фрагментироваться, но это очень нежелательно.
MFT и его структура.
Файловая система NTFS представляет собой выдающееся достижение
структуризации: каждый элемент системы представляет собой файл - даже
служебная информация. Самый главный файл на NTFS называется MFT, или
Master File Table - общая таблица файлов. Именно он размещается в MFT
зоне и представляет собой централизованный каталог всех остальных файлов
диска, и себя самого. MFT поделен на записи фиксированного размера
(обычно 1 Кбайт), и каждая запись соответствует, какому либо файлу (в
общем смысле этого слова). Первые 16 файлов носят служебный характер и
недоступны операционной системе - они называются метафайлами, причем
самый первый метафайл - сам MFT. Эти первые 16 элементов MFT -
единственная часть диска, имеющая фиксированное положение. Интересно,
что вторая копия этих же 16 записей, для надежности (они очень важны)
хранится ровно посередине диска. Остальной MFT-файл может располагаться, как и любой другой файл, в произвольных местах диска - восстановить его положение можно с помощью его самого, "зацепившись" за самую основу – за первый элемент MFT.
Метафайлы.
Первые 16 файлов NTFS (метафайлы) носят служебный характер. Каждый из
них отвечает за какой-либо аспект работы системы. Преимущество настолько
модульного подхода заключается в поразительной гибкости - например, на
FAT-е физическое повреждение в самой области FAT фатально для
функционирования всего диска, а NTFS может сместить, даже фрагментировать по диску, все свои служебные области, обойдя любые
неисправности поверхности - кроме первых 16 элементов MFT. Метафайлы
находятся корневом каталоге NTFS диска - они начинаются с символа имени
"$", хотя получить какую-либо информацию о них стандартными средствами
сложно. Любопытно, что и для этих файлов указан вполне реальный размер -
можно узнать, например, сколько операционная система тратит на
каталогизацию всего вашего диска, посмотрев размер файла $MFT. В
следующей таблице приведены используемые в данный момент метафайлы и их назначение.
Название метафайла. Описание
- $MFT сам MFT;
- $MFTmirr копия первых 16 записей MFT, размещенная посередине диска;
- $LogFile файл поддержки журналирования;
- $Volume Служебная информация - метка тома, версия файловой системы, т.д.;
- $AttrDef Список стандартных атрибутов файлов на томе;
- $. Корневой каталог;
- $Bitmap карта свободного места тома;
- $Boot Загрузочный сектор (если раздел загрузочный);
- $Quota файл, в котором записаны права пользователей на использование
дискового пространства (начал работать лишь в NT5);
-$Upcase файл – таблица соответствия заглавных и прописных букв в имени
файлов на текущем томе. Нужен в основном потому, что в NTFS имена файлов записываются в Unicode, что составляет 65 тысяч различных символов, искать большие и малые эквиваленты которых очень нетривиально.
Файлы и потоки.
Итак, у системы есть файлы - и ничего кроме файлов. Что включает в себя
это понятие на 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-ти. Экономия времени поиска налицо. Не стоит, однако
думать, что в традиционных системах (FAT) всё так запущено: во-первых,
поддержание списка файлов в виде бинарного дерева довольно трудоемко, а
во-вторых - даже FAT в исполнении современной системы (Windows2000 или
Windows98) использует сходную оптимизацию поиска. Это просто еще один
факт, который следует знать. Хочется также развеять распространенное
заблуждение о том, что добавлять файл в каталог в виде дерева труднее,
чем в линейный каталог: это достаточно сравнимые по времени операции -
дело в том, что для того, чтобы добавить файл в каталог, нужно сначала
убедится, что файла с таким именем там еще нет, и вот тут-то в линейной
системе у нас будут трудности с поиском файла, описанные выше, которые с
лихвой компенсируют саму простоту добавления файла в каталог. Какую
информацию можно получить, просто прочитав файл каталога? Ровно то, что
выдает команда dir. Для выполнения простейшей навигации по диску не
нужно лазить в MFT за каждым файлом, надо лишь читать самую общую
информацию о файлах из файлов каталогов. Главный каталог диска -
корневой - ничем не отличается от обычных каталогов, кроме специальной
ссылки на него из начала метафайла MFT.
Журналирование.
NTFS - отказоустойчивая система, которая вполне может привести себя в
корректное состояние при практически любых реальных сбоях. Любая
современная файловая система основана на таком понятии, как транзакция -
действие, совершаемое целиком и корректно или не совершаемое вообще. У
NTFS просто не бывает промежуточных (ошибочных или некорректных)
состояний - квант изменения данных не может быть поделен на до и после
сбоя, принося разрушения и путаницу - он либо совершен, либо отменен.
Чтобы ощутить плюсы журналирования, давайте рассмотрим некоторые
примеры:
Пример 1: осуществляется запись данных на диск. Вдруг выясняется, что в
то место, куда мы только что решили записать очередную порцию данных,
писать не удалось - физическое повреждение поверхности. Поведение NTFS в этом случае довольно логично: транзакция записи откатывается целиком -
система осознает, что запись не произведена. Место помечается как
сбойное, а данные записываются в другое место - начинается новая
транзакция.
Пример 2: более сложный случай - идет запись данных на диск. Вдруг
отключается питание и система перезагружается. На какой фазе
остановилась запись, где есть данные, а где «мусор»? На помощь приходит
другой механизм системы - журнал транзакций. Дело в том, что система,
осознав свое желание писать на диск, пометила в метафайле $LogFile это
свое состояние. При перезагрузке это файл изучается на предмет наличия
незавершенных транзакций, которые были прерваны аварией и результат
которых непредсказуем - все эти транзакции отменяются: место, в которое
осуществлялась запись, помечается снова как свободное, индексы и
элементы MFT приводятся в с состояние, в котором они были до сбоя, и
система в целом остается стабильна. Ну а если ошибка произошла при
записи в журнал? Тоже ничего страшного: транзакция либо еще и не
начиналась (идет только попытка записать намерения её произвести), либо
уже закончилась - то есть идет попытка записать, что транзакция на самом
деле уже выполнена. В последнем случае при следующей загрузке система
сама вполне разберется, что на самом деле всё и так записано корректно,
и не обратит внимания на пометку о незаконченную транзакции.
И все-таки журналирование - не абсолютная панацея, а лишь средство
существенно сократить число ошибок и сбоев системы. Вряд ли рядовой
пользователь NTFS хоть когда-нибудь заметит ошибку системы или вынужден будет запускать chkdsk - опыт показывает, что NTFS восстанавливается полностью в корректное состояние даже при сбоях в очень загруженные дисковой активностью моменты. Вы можете даже оптимизировать диск и в самый разгар этого процесса нажать reset - вероятность потерь данных даже в этом случае будет очень низка. Важно понимать, однако, что система восстановления NTFS гарантирует корректность файловой системы, а не ваших данных. Если вы производили запись на диск и получили аварию - ваши данные могут и не записаться. Чудес не бывает.
Сжатие.
Файлы NTFS имеют один довольно полезный атрибут - "сжатый". Дело в том, что NTFS имеет встроенную поддержку сжатия дисков - то, для чего раньше приходилось использовать Stacker или DoubleSpace. Любой файл или каталог в индивидуальном порядке может храниться на диске в сжатом виде – этот процесс совершенно прозрачен для приложений. Сжатие файлов имеет очень высокую скорость и только одно большое отрицательное свойство – огромная виртуальная фрагментация сжатых файлов, которая, правда, никому особо не мешает. Сжатие осуществляется блоками по 16 кластеров и использует так называемые "виртуальные кластеры" - опять же предельно гибкое решение, позволяющее добиться интересных эффектов - например, половина файла может быть сжата, а половина - нет. Это достигается благодаря тому, что хранение информации о компрессированности определенных фрагментов очень похоже на обычную фрагментацию файлов. Наглядно это можно изобразить следующим образом:
Видно, что сжатый файл имеет "виртуальные" кластеры, реальной информации в которых нет. Как только система видит такие виртуальные кластеры, она тут же понимает, что данные предыдущего блока, кратного 16-ти, должны быть разжаты, а получившиеся данные как раз заполнят виртуальные кластеры - вот, по сути, и весь алгоритм.
Безопасность.
NTFS содержит множество средств разграничения прав объектов - есть
мнение, что это самая совершенная файловая система из всех ныне
существующих. В теории это, без сомнения, так, но в текущих реализациях,
к сожалению, система прав достаточно далека от идеала и представляет
собой хоть и жесткий, но не всегда логичный набор характеристик. Права,
назначаемые любому объекту и однозначно соблюдаемые системой,
эволюционируют - крупные изменения, и дополнения прав осуществлялись уже несколько раз и к Windows 2000 все-таки они пришли к достаточно
разумному набору. Права файловой системы NTFS неразрывно связаны с самой системой - то есть они, вообще говоря, необязательны к соблюдению другой системой, если ей дать физический доступ к диску. Для предотвращения физического доступа в Windows2000 (NT5) всё же ввели стандартную возможность - об этом см. ниже. Система прав в своем текущем состоянии достаточно сложна, и ее описание далеко выводит за рамки нашей темы.
В принципе, на этом описание строения файловой системы можно закончить,
осталось лишь некоторое количество просто практичных и оригинальных
вещей:
Hard Links. Эта штука была в NTFS с незапамятных времен, но использовалась очень редко - и тем не менее: Hard Link - это когда один
и тот же файл имеет два имени (несколько указателей файла-каталога или
разных каталогов указывают на одну и ту же MFT запись). Допустим, один и
тот же файл имеет имена 1.txt и 2.txt: если пользователь сотрет файл 1,
останется файл 2. Если сотрет 2 - останется файл 1, т. е. оба имени, с
момента создания, совершенно равноправны. Файл физически стирается лишь тогда, когда будет удалено его последнее имя.
Symbolic Links (NT5). Гораздо более практичная возможность, позволяющая
делать виртуальные каталоги. Говоря иными словами, позволяет монтировать каталоги. Например, чтобы постоянно не использовать каталог с длинным именем, например C:\documents and settings\administrator\my documents, его можно смотировать в другой каталог, например в C:\doc, при этом данный каталог будет являться виртуальным, то есть содержать просто
ссылку на изначальный каталог, что очень удобно. Если возникнет желание
разорвать связь виртуального и монтируемого каталогов, то нужно быть
осторожным, так как при попытке удалить его при помощи, например, FAR’а, удалиться сам монтируемый каталог! Для удаления связей можно
использовать стандартную команду rd из командной строки.
Шифрование (NT5). Полезная возможность для людей, которые беспокоятся за свои секреты - каждый файл или каталог может также быть зашифрован, что не даст возможность прочесть его другой инсталляцией NT. В сочетании со стандартным и практически непрошибаемым паролем на загрузку самой
системы, эта возможность обеспечивает достаточную для большинства
применений безопасность избранных вами важных данных. Более подробно об этом ниже, так как тема достаточно обширна и интересна.
Дефрагментация NTFS
Достаточно интересный момент – это фрагментация и дефрагментация NTFS.
Дело в том, что ситуация, сложившаяся с этими двумя понятиями в
настоящий момент, никак не может быть названа удовлетворительной. В
самом начале утверждалось, что NTFS не подвержена фрагментации файлов.
Это оказалось не совсем так, и утверждение сменили - NTFS препятствует
фрагментации. Оказалось, что и это не совсем так. То есть она, конечно,
препятствует, но толк от этого близок к нулю... Сейчас уже понятно, что
NTFS - система, которая как никакая другая предрасположена к
фрагментации, что бы ни утверждалось официально. Единственное что -
логически она не очень от этого страдает. Все внутренние структуры
построены таким образом, что фрагментация не мешает быстро находить
фрагменты данных. Но от физического последствия фрагментации - лишних
движений головок - она, конечно, не спасает. Мы же попробуем выяснить,
почему так происходит. Как известно, система сильнее всего фрагментирует
файлы, когда свободное место кончается, когда приходится использовать
мелкие дырки, оставшиеся от других файлов. Тут возникает первое свойство
NTFS, которое прямо способствует серьезной фрагментации. Диск NTFS
поделен на две зоны. В начале диска идет MFT зона - зона, куда растет
MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных
в эту зону невозможна. Это сделано для того, чтобы не фрагментировался
хотя бы MFT. Но когда весь остальной диск заполняется - зона сокращается
ровно в два раза. И так далее. Таким образом, мы имеем не один заход
окончания диска, а несколько. В результате если NTFS работает при диске,
заполненном примерно на 90% - фрагментация растет как бешенная. Попутное неприятное следствие состоит в том, что диск, заполненный более чем на 88%, дефрагментировать почти невозможно - даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра. Но и это еще не все. NTFS фрагментируется даже в том случае, если свободное место далеко от
истощения. Этому способствует странный алгоритм нахождения свободного
места для записи файлов - второе серьезное упущение. Алгоритм действий
при любой записи такой: берется какой-то определенный объем диска и
заполняется файлом до упора. Причем по очень интересному алгоритму:
сначала заполняются большие дырки, потом маленькие. Т.е. типичное
распределение фрагментов файла по размеру на фрагментированной NTFS
выглядит так (размеры фрагментов):
16-16-16-16-16 – (скачок назад) – 15-15-15-15 – (скачок назад) …
Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что
на диске наверняка есть и гораздо более большие куски свободного места.
А если еще вспомнить сжатые файлы - при активной перезаписи больших
объемов сжатой информации на NTFS образуется гигантское количество
"дырок" из-за перераспределения на диске сжатых объемов - если
какой-либо участок файла стал сжиматься лучше или хуже, его приходится,
либо изымать из непрерывной цепочки и размещать в другом месте, либо
стягивать в объеме, оставляя за собой дырку. Вот и получается в итоге,
что NTFS не препятствует фрагментации, а наоборот, с «радостью»
фрагментирует даже то, что можно было не фрагментировать.
Средства решения проблем фрагментации.
В NT существует стандартное API дефрагментации. Обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. А из этого следует вот что:
в дырку свободного места менее 16 кластеров нельзя ничего переместить
(кроме сжатых файлов, но это неинтересные в данный момент тонкости).
Файл, будучи перемещенный в другое место, оставляет после себя (на новом
месте) "временно занятое место", дополняющее его по размеру до кратности
16 кластерам. При попытке как-то неправильно ("не кратно 16") переместить файл, результат часто непредсказуем. Что-то округляется, что-то просто не
перемещается… Тем не менее, всё место действия щедро рассыпается
"временно занятым местом" ("временно занятое место" служит для облегчения восстановления системы в случае аппаратного сбоя и
освобождается через некоторое время, обычно где-то пол минуты).
Тем не менее, логично было бы использовать этот API, раз он есть. Его и
используют. И этот процесс дефрагментации состоит из следующих фаз:
- Вынимание файлов из MFT зоны. Не специально – просто вернуть их туда
обратно не представляется возможным. Безобидная фаза, и даже в чем то
полезная.
- Дефрагментация файлов. Безусловно, полезный процесс, несколько, правда,
осложняемый ограничениями кратности перемещений - файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
- Дефрагментация MFT, файла виртуальной памяти (pagefile.sys) и каталогов.
Возможна через API только в Windows2000, иначе - при перезагрузке,
отдельным процессом.
- Складывание файлов ближе к началу - так называемая дефрагментация
свободного места. Вот об этом страшном процессе подробнее.
Допустим, мы хотим положить файлы подряд в начало диска. Кладем один
файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем
следующий - после хвоста, естественно. Через некоторое время, по
освобождению хвоста, имеем дырку размером менее 16 кластеров, которую
потом невозможно заполнить через API дефрагментации! В результате, до
оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких (менее 16 кластеров) дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно,
находящиеся ближе к началу диска мелкие дырки менее 16 кластеров. Любой
файл, плавно созданный на прооптимизированном диске, будет состоять из
дикого числа фрагментов, что потребует очередной оптимизации диска уже
через неделю! Таким образом, имеется два примерно равнозначных варианта.
Первый - часто оптимизировать диск таким дефрагментатором, смирясь при
этом с дикой фрагментацией заново созданных файлов. Второй вариант -
вообще ничего не трогать, и смириться с равномерной, но гораздо более
слабой фрагментацией всех файлов на диске. Но есть еще один способ –
использовать дефрагментатор, который игнорирует API. На сегодняшний день существует один такой дефрагментатор – Norton SpeedDisk 5.x для NT. Все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом и состоит основная суть сложности фрагметирования и дефрагментирования файлов.
Программный RAID.
Журналирование NTFS, как уже указывалось ранее, ни в коей мере не
гарантирует от сбоев с потерей пользовательской информации. Между тем,
NT предлагает несколько вариантов создания систем, где, в разумных
условиях, гарантируется абсолютно всё. Можно также использовать большее
число дисков для обеспечения не повышенной надежности, а, наоборот,
повышенной скорости - или того и другого одновременно. О таких
конфигурациях и пойдет речь в этой части.
RAID (Redundant Array of Inexpensive Disks) - избыточный массив
недорогих дисков. Технология, заключающаяся в одновременном
использовании нескольких дисковых устройств для обеспечения
характеристик надежности или скорости, отсутствующих у накопителей в
отдельности. Windows NT поддерживает на программном уровне три уровня
RAID (так называются стратегии работы дисковых массивов. Вообще
существует 10 уровней RAID – RAID 0,1,2,3,4,5,6,7,10,53).
Шифрующая файловая система (EFS).
Шифрующая файловая система (Encrypting File System) - это тесно
интегрированная с NTFS служба, располагающаяся в ядре Windows 2000. Ее
назначение: защита данных, хранящихся на диске, от несанкционированного
доступа путем их шифрования. Появление этой службы не случайно, и
ожидалось давно. Дело в том, что существующие на сегодняшний день
файловые системы не обеспечивают необходимую защиту данных от
несанкционированного доступа. Вероятно, опытные пользователи могут
возразить, сказав, что в NTFS есть функция разграничения доступа,
которая позволит защитить данные от несанкционированного доступа. Да,
это так. Но что, если доступ к разделу будет осуществляться не через NT,
a напрямую на физическом уровне? Ведь это легко организовать при помощи
той же системной дискеты. Загрузившись с нее можно будет просмотреть
нужные данные и никакие ограничения NT не помогут. Конечно, можно
предусмотреть это и запретить загрузку с дискет или CD-ROM и поставить
пароль на BIOS. Но такая защита малоэффективна, так как если есть
возможность вынести винчестер, то это не спасет ваши данные. Остается
один выход – зашифровать их. Самый простой способ – архивирование файлов с паролем. Однако здесь есть ряд серьезных недостатков. Во-первых,
пользователю требуется каждый раз вручную шифровать и дешифровать (то
есть, в нашем случае архивировать и разархивировать) данные перед
началом и после окончания работы, что уже само по себе уменьшает
защищенность данных. Пользователь может забыть зашифровать
(заархивировать) файл после окончания работы, или (еще более банально)
просто оставить на диске копию файла. Во-вторых, пароли, придуманные
пользователем, как правило, легко угадываются. В любом случае,
существует достаточное количество программ, позволяющих распаковывать
архивы, защищенные паролем. Как правило, такие программы осуществляют
подбор пароля путем перебора слов, записанных в словаре. С целью
преодоления всех этих недостатков и была разработана система EFS. EFS
использует архитектуру Windows CryptoAPI. В ее основе лежит технология
шифрования с открытым ключом. Для шифрования каждого файла случайным образом генерируется ключ шифрования файла. При этом для шифрования файла может применяться любой симметричный алгоритм шифрования. В настоящее же время в EFS используется один алгоритм, это DESX, являющийся специальной модификацией широко распространенного стандарта DES. Ключи шифрования EFS хранятся в резидентном пуле памяти (сама EFS расположена в ядре Windows 2000), что исключает несанкционированный доступ к ним через файл подкачки.
По умолчанию EFS сконфигурирована таким образом, что пользователь может сразу начать использовать шифрование файлов. Операция шифрования и обратная поддерживаются для файлов и каталогов. В том случае, если шифруется каталог, автоматически шифруются все файлы и подкаталоги этого каталога. Необходимо отметить, что если зашифрованный файл перемещается или переименовывается из зашифрованного каталога в незашифрованный, то он все равно остается зашифрованным. Операции шифрования/дешифрования можно выполнить двумя различными способами - используя Windows Explorer или консольную утилиту Cipher. Для того чтобы зашифровать каталог из Windows Explorer, пользователю нужно просто выбрать один или несколько каталогов и установить флажок шифрования в окне расширенных свойств каталога. Все создаваемые позже файлы и подкаталоги в этом каталоге будут также зашифрованы. Таким образом, зашифровать файл можно, просто скопировав (или перенеся) его в "зашифрованный" каталог. Зашифрованные файлы хранятся на диске в зашифрованном виде. При чтении файла данные автоматически расшифровываются, а при записи - автоматически шифруются.
Пользователь может работать с зашифрованными файлами так же, как и с
обычными файлами, то есть открывать и редактировать в текстовом
редакторе Microsoft Word документы, редактировать рисунки в Adobe
Photoshop или графическом редакторе Paint, и так далее. Необходимо
отметить, что ни в коем случае нельзя шифровать файлы, которые
используются при запуске системы - в это время личный ключ пользователя,
при помощи которого производится дешифровка, еще недоступен. Это может
привести к невозможности запуска системы! В EFS предусмотрена простая
защита от таких ситуаций: файлы с атрибутом "системный" не шифруются.
Однако будьте внимательны: это может создать "дыру" в системе
безопасности! Проверяйте, не установлен ли атрибут файла "системный" для
того, чтобы убедиться, что файл действительно будет зашифрован. Важно
также помнить о том, что зашифрованные файлы не могут быть сжаты
средствами Windows 2000 и наоборот. Иными словами, если каталог сжат,
его содержимое не может быть зашифровано, а если содержимое каталога
зашифровано, то он не может быть сжат. В том случае, если потребуется
дешифровка данных, необходимо просто снять флажки шифрования у выбранных каталогов в Windows Explorer, и файлы и подкаталоги автоматически будут дешифрованы. Следует отметить, что эта операция обычно не требуется, так как EFS обеспечивает "прозрачную" работу с зашифрованными данными для пользователя.
Восстановление данных.
EFS обеспечивает встроенную поддержку восстановления данных на тот
случай, если потребуется их расшифровать, но, по каким-либо причинам,
это не может быть выполнено обычным способом. По умолчанию, EFS
автоматически сгенерирует ключ восстановления, установит сертификат
доступа в учетной записи администратора и сохранит его при первом входе
в систему. Таким образом, администратор становится так называемым
агентом восстановления, и сможет расшифровать любой файл в системе.
Разумеется, политику восстановления данных можно изменить, и назначить в
качестве агента восстановления специального человека, ответственного за
безопасность данных, или даже несколько таких лиц. Итак, коротко факты о
EFS:
Система EFS в Windows 2000 предоставляет пользователям возможность
зашифровывать каталоги NTFS, используя устойчивую, основанную на общих ключах криптографическую схему, при этом все файлы в закрытых каталогах будут зашифрованы. Шифрование отдельных файлов поддерживается, но не рекомендуется из-за непредсказуемого поведения приложений.
Система EFS также поддерживает шифрование удаленных файлов, доступ к
которым осуществляется как к совместно используемым ресурсам. Если имеют место пользовательские профили для подключения, используются ключи и сертификаты удаленных профилей. В других случаях генерируются локальные профили и используются локальные ключи.
Система EFS предоставляет установить политику восстановления данных
таким образом, что зашифрованные данные могут быть восстановлены при
помощи EFS, если это потребуется.
Политика восстановления данных встроена в общую политику безопасности
Windows 2000. Контроль за соблюдением политики восстановления может быть делегирован уполномоченным на это лицам. Для каждого подразделения организации может быть сконфигурирована своя политика восстановления данных.
Восстановление данных в EFS - закрытая операция. В процессе
восстановления расшифровываются данные, но не ключ пользователя, при
помощи которого эти данные были зашифрованы.
Работа с зашифрованными файлами в EFS не требует от пользователя
каких-либо специальных действий по шифрованию и дешифрованию данных. Дешифрование и шифрование происходят незаметно для пользователя в процессе считывания и записи данных на диск.
Система EFS поддерживает резервное копирование и восстановление
зашифрованных файлов без их расшифровки. Программа NtBackup поддерживает резервное копирование зашифрованных файлов.
Система EFS встроена в операционную систему таким образом, что утечка
информации через файлы подкачки невозможна, при этом гарантируется, что
все создаваемые копии будут зашифрованы. Предусмотрены многочисленные меры предосторожности для обеспечения безопасности восстановления данных, а также защита от утечки и потери данных в случае фатальных сбоев системы.
Влияние различных факторов на быстродействие NTFS.
Для удобства сравнения, факторы будут взяты те же, по которым проводился
анализ быстродействия FAT 32. Так как общие слова о значении каждого
параметра были сказаны в описании FAT 32, поясняться каждый параметр не
будет, а будет сразу написано влияние этого параметра на NTFS.
Поиск данных файла.
NTFS способна обеспечить быстрый поиск фрагментов, поскольку вся
информация хранится в нескольких очень компактных записях (типичный
размер - несколько килобайт). Если файл очень сильно фрагментирован, то
NTFS придется использовать много записей, что часто заставит хранить их
в разных местах. Лишние движения головок при поиске этих данных, в таком
случае, приведут к сильному замедлению процесса поиска данных о
местоположении файла. Как вывод, можно сказать, что NTFS показывает себя довольно таки неплохо, так как эта система не требует чтения лишней
информации до того момента, пока файл имеет разумно число фрагментов.
Поиск свободного места.
В отличие от FAT 32, NTFS имеет битовую карту свободного места (то есть
одному кластеру соответствует один бит). Следовательно, для поиска
свободного места на диске NTFS не придется оценивать большие объемы
информации.
Работа с каталогами и файлами.
NTFS использует достаточно эффективный способ адресации – бинарное
дерево. Такая организация позволяет эффективно работать с каталогами
любого размера (NTFS показывает высокое быстродействие даже в каталогах, где количество файлов превышает десятки тысяч). Подробнее о структуре каталогов было написано выше.
Кэширование.
NTFS, к сожалению, имеет большие требования к памяти, необходимой для
работы системы. Прежде всего, кэширование сильно затрудняет большие
размеры каталогов. Размер одних только каталогов, с которыми активно
ведет работу система, может запросто доходить до нескольких Мбайт и даже
десятков Мбайт! Добавьте к этому необходимость кэшировать карту
свободного места тома (сотни Кбайт) и записи MFT для файлов, с которыми
осуществляется работа (в типичной системе - по 1 Кбайт на каждый файл).
К счастью, NTFS имеет удачную систему хранения данных, которая не
приводит к увеличению каких-либо фиксированных областей при увеличении объема диска. Количество данных, с которым оперирует система на основе NTFS, практически не зависит от объема тома, и основной вклад в объемы данных, которые необходимо кэшировать, вносят каталоги. Тем не менее, уже этого вполне достаточно для того, чтобы только минимальный объем данных, необходимых для кэширования базовых областей NTFS, доходил до 5 - 8 Мбайт. Поэтому можно с уверенностью сказать, что NTFS теряет огромное количество своего теоретического быстродействия из-за
недостаточного кэширования. 64 Мбайта ОЗУ для NTFS – самый минимум! Но даже такой объем памяти не дает возможности организовать наиболее
эффективную работу NTFS. Системы с большим объемом памяти (лучше всего 128 Мбайт и более) смогут уверенно кэшировать все, что необходимо для работы систем. На таких машинах NTFS покажет максимальное
быстродействие.
Быстродействие накопителя.
Время случайного доступа (random seek time). К сожалению, для доступа к
системным областям на типичном диске более сложной файловой системы
(NTFS) приходится совершать, в среднем, больше движений головками диска, чем в более простых системах (FAT16 и FAT32). Гораздо большая
фрагментация каталогов, возможность фрагментации системных областей -
всё это делает диски NTFS гораздо более чувствительными к скорости
считывания произвольных (случайных) областей диска. По этой причине
использовать NTFS на медленных (старых) дисках не рекомендуется.
Наличие Bus Mastering. Система запаздывающего кэширования NTFS сможет
действовать гораздо более эффективно при наличии Bus Mastering, так как
NTFS производит отложенную запись гораздо большего числа данных. Системы без Bus Mastering в настоящее время встречаются достаточно редко (обычно это накопители или контроллеры, работающие в режиме PIO3 или PIO4), и если вы работаете с таким диском - то, скорее всего, NTFS потеряет еще пару очков быстродействия, особенно при операциях модификации каталогов (например, активная работа в интернете - работа с кэшем интернета).
Кэширование как чтения, так и записи на уровне жестких дисков (объем
буфера HDD - от 128 Кбайт до 1-2 Мбайт в современных дорогих дисках).
NTFS из соображений надежности хранения информации осуществляет
модификацию системных областей с флагом "не кэшировать запись", поэтому быстродействие системы NTFS слабо зависит от возможности кэширования самого HDD.
Размер кластера.
Типичный размер кластера для NTFS - 4 Кбайта. Стоит отметить, что при
большем размере кластера отключается встроенная в файловую систему
возможность сжатия индивидуальных файлов, а также перестает работать
стандартный API дефрагментации - т.е. подавляющее число
дефрагментаторов, в том числе встроенный в Windows 2000, будут
неспособны дефрагментировать этот диск. SpeedDisk, впрочем, сможет - он
работает без использования данного API. Оптимальным с точки зрения
быстродействия, по крайней мере, для средних и больших файлов, считается
(самой Microsoft) размер 16 Кбайт. Увеличивать размер далее неразумно
из-за слишком больших расходов на неэффективность хранения данных и
из-за мизерного дальнейшего увеличения быстродействия. Если вы хотите
повысить быстродействие NTFS ценой потери возможности сжатия -
задумайтесь о форматировании диска с размером кластера, большим чем 4
Кбайта. Но имейте в виду, что это даст довольно скромный прирост
быстродействия, который часто не стоит даже уменьшения эффективности
размещения файлов на диске.
Некоторые другие соображения.
NTFS является достаточно сложной системой, поэтому, в отличие от FAT и
FAT32, имеются и другие факторы, которые могут привести к существенному замедлению работы NTFS:
Диск NTFS был получен преобразованием раздела FAT или FAT32
(специальной программой, напр. Partition Magic). Данная процедура в
большинстве случаев представляет собой тяжелый случай для
быстродействия, так как структура служебных областей NTFS, скорее всего,
получится очень фрагментированной. Если есть возможность необходимо
избегать преобразования других систем в NTFS, так как это приведет к
созданию очень неудачного диска, которому не поможет даже типичный
(неспециализированный) дефрагментатор, типа Diskeeper-а или встроенного
в Windows 2000.
Активная работа с диском, заполненным более чем на 80% - 90%,
представляет собой катастрофический для быстродействия NTFS случай, так
как фрагментация файлов и, самое главное, служебных областей, будет
расти фантастически быстро. Если ваш диск используется в таком режиме -
FAT32 будет более удачным выбором при любых других условиях.