Файловые системы

Санкт-Петербургский  государственный экономический  университет 

 

Факультет менеджмента

 

 

 

 

«Файловые системы»

 

Реферат

 

 

 

 

Выполнил:

Студент группы 1311

Сметанкин В. В.

Научный руководитель:

 

 

 

 

Санкт-Петербург 2013

 

 

 

 

СОДЕРЖАНИЕ 
 
1.Введение                                                                                          ст. 2 
 
2.Файловая система FAT                                                                   ст. 2-3

3.Файловая система  FAT32                                                              ст. 3-8  

3.1. Поиск данных файла                                                                   ст. 3-4 
 
3.2. Поиск свободного места                                                             ст. 4-5 
 
3.3. Работа с каталогами и файлами                                                 ст. 5 
 
3.4. Кэширование                                                                                ст. 5-6 
 
3.5. Быстродействие накопителя                                                       ст. 6-7 
 
3.6. Размер кластера                                                                            ст. 7 
 
3.7. Вывод                                                                                            ст. 8 
 
4.Файловая система NTFS                                                                 ст. 9-25 
 
4.1. Физическая структура NTFS                                                       ст. 9-26 
 
4.2. Дефрагментация NTFS                                                                 ст.16-19 
 
4.3. Программный RAID                                                                     ст. 19 
 
4.4. Шифрующая файловая система (EFS)                                        ст. 19-22 
 
4.5. Влияние различных факторов на быстродействие NTFS          ст. 22-25 
 
4.6 Вывод                                                                                               ст. 25 
 
5.Список использованной литературы.                                              ст. 26 
 

 

 

 

 

 

 

 

 

 

 

1.Введение.

В настоящее время существует множество файловых систем. Для начала необходимо разобраться, что же такое файловая система? И что же такое файл? Файловая система – это способ организации файлов на диске. Наиболее распространены такие файловые системы, как FAT, FAT32, NTFS, Linux Ext2, Linux Swap. Каждая операционная система (далее ОС) использует свою файловую систему. Например, для Linux это Linux Ext2 и Linux Swap, для DOS, Windows 95/98/ME, Windows NT/2000/XP – FAT, для Windows 95 OEM release 2/98/ME/NT/2000/XP – FAT32 и для Windows NT/2000/XP – NTFS.

В файловых системах FAT, FAT32, NTFS файлы  хранятся в, так называемых, кластерах. Кластер – это минимальная единица распределения в файловых системах FAT, FAT32, NTFS. Один кластер состоит из фиксированного числа дисковых секторов. Причем, при помощи специальных утилит размер кластера можно задавать самому. Кластер не может быть по размеру меньше, чем один дисковый сектор (в большинстве современных винчестеров - 512 байт). Если провести обзор файловых систем, то можно выяснить их плюсы и минусы.

2.Файловая система FAT.

Файловая система FAT (File Allocation Table) использовалась во всех версиях ОС Ms-DOS, а также в OS/2 (в версиях 1.0 и 1.1) и первых релизах Windows 95. Указанная файловая система вполне удовлетворяла требованиям своего времени в основном благодаря тому, что сама по себе очень компактна и проста. Благодаря этому она с легкостью использовалась на гибких носителях. Для хранения файла в FAT может использоваться один или несколько кластеров. Каждому кластеру диска в таблице FAT соответствует отдельная запись, которая либо указывает на следующий кластер файла, либо содержит метку конца файла. В составе каждого каталога хранятся имена входящих в него файлов. Вместе с именем файла хранится указатель на первый кластер этого файла. Помимо этого в каталоге хранится дата создания файла, его размер и атрибуты. Атрибуты могут указывать на то, что файл является скрытым, зарезервированным для использования операционной системой, требует архивирования (резервного копирования) или предназначен только для чтения. Казалось бы, при такой организации хранения данных, система должна быть достаточно быстрой и надежной. 
 
Давайте же рассмотрим ее недостатки. Самый первый и главный недостаток, с которым мы сталкиваемся при использовании FAT – это слишком сильная ограниченность максимального размера тома FAT. Цифра 16 в названии FAT 16 означает, что таблица размещения файлов FAT идентифицирует записи, соответствующие дисковым кластерам, при помощи 16-разрядных чисел. Таким образом, в таблице можно разместить не более 65 536 записей (2 в 16-ой степени). А если учитывать то, что максимальный размер кластера – 32 Кбайта, то выходит, что максимальный раздел дискового тома - 2 Гбайта. Естественно, что эта система не удовлетворяет современным винчестерам, имеющим объемы в десятки гигабайтВторой недостаток заключается в том, что для хранения всех файловых атрибутов система FAT использует всего 1 байт! Много ли можно поместить в один байт? Следовательно, просто не 
представляется возможности хранить данные о правах доступа к файлу, о его владельце и т.д. Недостаток номер три – при использовании большего размера тома мы вынуждены использовать больший размер кластера. Однако, в FAT один файл занимает как минимум один кластер. Например, при размере кластера в 32 Кбайта мы имеем файл, размером 2 Кбайта – в результате файл занимает весь кластер, и мы теряем 30 Кбайт. Таким образом, получается, что физически файл занимает не 2, а все 32 Кбайта! Четвертый недостаток – сведения о физическом расположении файлов хранятся в одном месте – таблице размещения файлов FAT. Это приводит к следующему: 
 
- увеличивается вероятность повреждения и потери всей информации; 
 
- снижается скорость поиска, т.к. для поиска определенного файла нужно 
обработать всю таблицу. 
 
Подводя итог вышесказанному, можно сделать вывод, что использовать FAT в настоящее время неэффективно. Но стоит заметить, что FAT создавалась довольно давно и удовлетворяла требованиям того времени.  

3.Файловая система FAT 32. 
 
Эта файловая система пришла на смену FAT, начиная с Windows 95 OEM release 2. Основное ее отличие от FAT заключается в том, что таблица размещения файлов FAT идентифицирует записи, соответствующие дисковым кластерам, при помощи 32-разрядных чисел. В соответствии с этим максимальное количество записей становится равным 4 294 967 296 (2 в 32-ой степени). Следовательно, существенно увеличивается максимальный размер тома (до 2 Тбайт). Но в остальном система осталась практически такой же. Однако необходимость работать с огромными по размеру томами и документами прямо указывает на недостатки FAT 32. Итак, рассмотрим их по порядку.  
 
Поиск данных файла. 
 
В данной подглаве рассматривается именно поиск информации. Доступ к самим данным (фрагментированы они или нет) здесь уже не рассматривается, так как этот процесс одинаков для всех систем. Речь идет о тех лишних действиях, которые придется выполнять системе перед доступом к реальным данным файлов. Этот параметр влияет на скорость доступа к произвольному фрагменту файла, показывает насколько сильно сама файловая система 
страдает от фрагментации файлов. И FAT 32 показывает себя здесь не лучшим образом. Из-за большой области самой таблицы размещения будет испытывать огромные трудности, если фрагменты файла разбросаны по всему диску. Дело в том, что таблица размещения файлов (FAT) представляет собой мини-образ диска, куда включен каждый его кластер. Для доступа к фрагменту файла в системе FAT32 (как и в FAT) приходится обращаться к соответствующей частичке FAT. Если файл, к примеру, расположен в трех фрагментах - в начале диска, в середине, и в конце - то в системе FAT нам придется обратиться к фрагменту FAT также в его начале, в середине и в конце. Если в FAT, где максимальный размер области FAT составляет 128 Кбайт, это не составляет проблемы (вся область FAT просто хранится в памяти, или же считывается с диска целиком за один проход и буферизируется), то в FAT32, которая имеет типичный размер области FAT порядка сотен килобайт (а на больших дисках - даже несколько мегабайт), это составляет достаточно серьезную проблему. Если файл расположен в разных частях диска - это вынуждает систему совершать движения головок винчестера столько раз, сколько групп фрагментов в разных областях имеет файл, а это очень и очень сильно замедляет процесс поиска фрагментов файла. Следовательно, FAT32 испытывает огромные трудности, вплоть до чтения лишних сотен килобайт из области FAT, если файл разбросан разным областям диска. Работа с внушительными по размеру файлами на FAT32 в любом случае сопряжена с огромными трудностями - понять, в каком месте на диске расположен тот или иной фрагмент файла, можно лишь изучив всю 
последовательность кластеров файла с самого начала, обрабатывая за один раз один кластер (через каждые 4 Кбайт файла в типичной системе). Стоит отметить, что если файл фрагментирован, но лежит компактной кучей фрагментов - FAT32 всё же не испытывает больших трудностей, так как физический доступ к области FAT будет также компактен и буферизован.  
 
Поиск свободного места.

Эта операция производится в том  случае, если необходимо создать файл с нуля, либо скопировать его на диск. Поиск места под физические данные файла зависит от того, как хранится информация о занятых участках диска. Этот параметр влияет на скорость создания больших файлов (при создании малых файлов разница в скорости различных файловых систем практически незаметна). Также влияет на сохранение или создание больших 
мультимедийных файлов, копирование больших объемов информации и т.д. Этот параметр показывает, насколько быстро система может найти место для записи на диск новых данных и какие операции для этого придется ей проделать. Как уже указывалось выше таблица размещения файлов FAT как бы мини-образ диска, куда включен каждый его кластер. Следовательно, чтобы системе на основе FAT 32 (как впрочем, и FAT 16) определить, свободен данный кластер или нет, ей необходимо просмотреть одну запись в FAT, соответствующую этому кластеру. Размер одной записи в FAT 32 составляет 32 бита. Для поиска свободного места на диске может потребоваться просмотреть почти весь FAT, а он в свою очередь может достигать нескольких Мегабайт (!!!), что ведет к катастрофическому замедлению работы. Поэтому для нахождения свободного метода применяются методы оптимизации, в результате чего достигается приемлемая скорость. Одно можно сказать наверняка - поиск свободного места при работе в DOS на FAT32 - катастрофический по скорости процесс, поскольку никакая оптимизация невозможна без поддержки хоть сколь серьезной операционной системы. 
 
Работа с каталогами и файлами. 
 
Каждая файловая система выполняет элементарные операции с файлами: доступ, удаление, создание, перемещение и т.д. Скорость работы этих операций зависит от принципов организации хранения данных об отдельных файлах и от устройства структур каталогов. Этот параметр влияет на скорость любых операций с файлом, в том числе на скорость любой операции доступа к файлу, особенно в каталогах с большим числом файлов (несколько тысяч). FAT 32 имеет очень компактные каталоги, размер каждой записи которых предельно мал. Более того, из-за сложившейся исторически системы хранения длинных имен файлов (более 11 символов), в каталогах систем FAT используется не очень эффективная и на первый взгляд неудачная, но зато очень экономная структура хранения этих самих длинных имен файлов. Работа с каталогами FAT производится достаточно быстро, так как в подавляющем числе случаев каталог (файл данных каталога) не фрагментирован и находится на диске в одном месте. Единственная проблема, которая может существенно понизить скорость работы каталогов FAT - большое количество файлов в одном каталоге (порядка тысячи или более). Система хранения данных - линейный массив - не позволяет организовать эффективный поиск файлов в таком каталоге, и для нахождения данного файла приходится перебирать большой объем данных (в среднем половину файла каталога). Из выше сказанного видно, что FAT 32 не может эффективно работать с каталогами, содержащими большое количество файлов. 
 
Кэширование. 
 
Очень многие данные современных файловых систем кэшируются или буферизируются в памяти компьютера, что позволяет избежать лишних операций физического чтения данных с диска. Для достаточно высокопроизводительной работы системы в кэше приходится хранить 
следующие данные: 
 
- данные о физическом местоположении всех открытых файлов. Это, прежде всего, позволит обращаться к системным файлам и библиотекам, доступ к которым идет буквально постоянно, без чтения служебной (не относящейся к самим файлам) информации с диска. Это же относится к тем файлам, которые исполняются в данный момент - т.е. к выполняемым модулям (.exe и .dll) активных процессов в системе. В эту категорию попадают также файлы 
системы, с которыми производится работа (прежде всего реестр и виртуальная память, различные .ini файлы, а также файлы документов и приложений);  
 
- данные о свободном месте диска - т.е. та информация, которая позволит найти место для сохранения на диск новых данных.  
 
В случае, если этот базовый объем информации не будет доступен прямо в оперативной памяти, системе придется совершать множество ненужных операций еще до того, как она начнет работу с реальными данными. И тут перед нами встает вопрос: каким же объемом свободной оперативной памяти надо располагать, чтобы эффективно работать с файловой системой? FAT 32 имеет очень мало данных, отвечающих за организацию файловой системы 
(как, впрочем, и FAT 16). Из служебных областей можно выделить саму область FAT (если в FAT 16 она не могла превышать 128 Кбайт, то в FAT 32 на томах порядка 5-10 Гбайт область FAT может занимать объем в несколько Мбайт). Это, пожалуй, единственный внушительный объем данных FAT 32, надежно кэшировать который не представляется возможным. Каталоги FAT очень компактны и редко занимают более одного кластера. Следовательно, на кэширование фрагментов области FAT, отвечающих за местоположение рабочих файлов, необходимо несколько Мбайт свободной оперативной памяти, что довольно таки немного по сравнению с той же NTFS. Однако лично я бы не стал использовать FAT 32 на дисках, объемом более 30 Гбайт, так как сама таблица FAT будет иметь просто огромный размер. Оптимальный вариант для использования FAT 32 – машины с малыми и средними винчестерами (до 10 Гбайт) и машинами, имеющими менее 64 Мбайт оперативной памяти. На остальных машинах лучше использовать NTFS.  
 
Быстродействие накопителя. 
 
Итак, влияют ли физические параметры вашего накопителя на быстродействие файловой системы? Да, влияют. Не сильно, но влияют (в данном случае не имеются ввиду отличия ATA-66 от ATA-100, а возможность файловой системы использовать те или иные плюсы винчестеров). Рассмотрим параметры винчестеров, влияющие на быстродействие системы: 
 
- Время случайного доступа (random seek time). Благодаря простоте 
организации файловой системы FAT 32 (и FAT 16), для доступа к системным 
областям на типичном диске не приходится совершать много движений 
головками диска, что является достаточно большим плюсом в пользу FAT.  
 
- Наличие Bus Mastering. Bus Mastering – специальный режим работы драйвера и контроллера, при использовании которого обмен с диском происходит без участия процессора. В настоящее время большинство IDE-контроллеров идут с системой Bus Mastering. Конечно такая система будет работать немного быстрее, но на быстродействие FAT она сказывается не очень сильно, в отличие от NTFS.  
 
- Кэширование чтения и записи на уровне жестких дисков (объем буфера HDD - от 128 Кбайт до 1-2 Мбайт в современных дорогих дисках) - фактор, 
который будет более полезен системам на основе FAT. Системы FAT, 
конечно, получат некоторый плюс, от кэширования записи на физическом 
уровне, всерьез принимать размер буфера винчестера при оценке 
быстродействия файловой системы не стоит. 
 
Подводя итоги, снова получим, что FAT 32 лучше покажет себя на более 
медленных винчестерах, чем та же NTFS. Это в очередной раз наталкивает 
на мысль об устаревании FAT как файловой системы вообще. 
 
Размер кластера. 
 
Размер кластера можно задать практически произвольно (от 512 байт до 32 
Кбайт). Больший размер кластера – это практически всегда большее 
быстродействие. Особенно размер кластера влияет на системы FAT 32. Дело 
в том, что увеличивая размер кластера, скажем в 2 раза, мы сокращаем 
область FAT в те же 2 раза (в связи с тем, что уменьшается количество 
кластеров на диске). В свою очередь сокращение области FAT в несколько 
раз даст заметное увеличение быстродействия, так как объем системных 
данных файловой системы сильно сократиться, следовательно, уменьшается и время, затрачиваемое на чтение данных о расположении файлов, и объем 
оперативной памяти, необходимый для буферизирования этой информации. 
Типичный размер кластера для FAT 32 также составляет 4 Кбайта, и 
увеличение его до 8, а то и 16 Кбайт будет достаточно разумным с точки 
зрения быстродействия для больших винчестеров (10 и более Гбайт). Не 
смотря на повышение быстродействия, повышение размера кластера не 
пройдет безнаказанно. Напомню, что в FAT один файл занимает минимум один кластер. Для примера, пусть у нас будет файл, размером 2 Кбайта. При 
размере кластера в 4 Кбайта, мы потеряем всего 2 Кбайта, а при размере 
кластера в 16 Кбайт, потеря составит уже 14 Кбайт. Поэтому не нужно, 
слишком увлекаться увеличением размеров кластера, потому как увеличение 
быстродействия скажется на свободном месте.  
 
Вывод. 
 
К какому же выводу можно прийти, проанализировав все выше написанное? Для начала необходимо рассмотреть все плюсы и минусы файловой системы FAT 32.  
 
FAT – плюсы: 
 
1.Не требуется большое количество оперативной памяти для эффективной 
работы с ней. 
 
2.Быстрая работа с малыми и средними каталогами. 
 
3.Диск совершает в среднем меньшее количество движений головками (в 
сравнении, например с NTFS). 
 
4.Достаточно эффективно работает на медленных дисках. Не требовательна к 
системам Bus Mastering. 
 
5.Быстрый доступ к данным на маленьких по объему винчестерах. 
 
6.Малый размер файла каталога позволяет практически всегда оставлять его 
не фрагментированным. 
 
FAT – минусы: 
 
1.Катастрофическая потеря быстродействия с увеличением фрагментации, 
особенно для больших дисков. 
 
2.Сложности с произвольным доступом к большим (~10% от объема винчестера и более) файлам. 
 
3.Очень медленная работа с каталогами, содержащими большое количество 
файлов. 
 
4.Одного байта явно недостаточно для хранения атрибутов файла, из-за 
этого нет возможности хранить данные о правах доступа к файлу, его 
владельце и т.д. 
 
Вывод напрашивается сам собой. FAT 32 как система уже отжила свое. Она 
показывает себя только на машинах с небольшими дисками и объемом ОЗУ 
менее 64 Мбайт. При лучшей машине гораздо удобней будет использовать 
NTFS как с точки зрения быстродействия, так и с точки зрения надежности. 
FAT 32 просто-напросто продлила жизнь файловой системе FAT, не более 
того.

4.Файловая система NTFS. 
 
Файловая система NTFS (расшифровывается как New Technology File System) 
была разработана достаточно давно для Windows NT. В настоящее время она 
является файловой системой всего семейства Microsoft Windows NT, а также 
Windows XP. NTFS достаточно сложная файловая система, поэтому изложение ее достоинств и недостатков необходимо будет представить в нескольких частях, что позволит как-то систематизировать огромное количество документаций по ней.

 
Физическая структура  NTFS. 
 
Начнем с общих фактов. Раздел NTFS, теоретически, может быть почти 
какого угодно размера. Она поддерживает огромные диски – до 16 Экзабайт 
(1 Экзабайт равен 1 073 741 824 Гигабайт). Насколько же это много? Для 
наглядности возмем простой пример: предположим, что диск способен 
записать 1 Мбайт в секунду, тогда чтобы записать 1 Экзабайт (один, а не 
шестнадцать) ему потребуется 1000 миллиардов секунд. В одном году 3 
миллиона секунд. Следовательно, чтобы сохранить 1 Экзабайт информации, 
диску потребуется 300 000 лет!!! Поддержки таких огромных дисков с 
запасом хватит на последующие сто лет развития вычислительной техники 
при любых темпах роста. Как обстоит с этим дело на практике? Почти так 
же. Максимальный размер раздела NTFS в данный момент ограничен лишь 
размерами жестких дисков. NT4, правда, будет испытывать проблемы при 
попытке установки на раздел, если хоть какая-нибудь его часть отступает 
более чем на 8 Гб от физического начала диска, но эта проблема касается, 
лишь загрузочного раздела. 
 
Лирическое отступление (особенности установки NT 4.0). Метод инсталляции NT4.0 на пустой диск довольно оригинален и может навести на неправильные мысли о возможностях NTFS. Если вы укажете программе установки, что желаете отформатировать диск в NTFS, максимальный размер, который она вам предложит, будет всего 4 Гб. Почему так мало, если размер раздела NTFS на самом деле практически неограничен? Дело в том, что установочная секция, как это ни парадоксально, просто не знает этой файловой системы. Программа установки форматирует этот диск в обычный FAT, максимальный размер которого в NT составляет 4 Гбайт (с использованием не совсем стандартного огромного кластера 64 Кбайта), и на этот FAT устанавливает NT. А вот уже в процессе первой загрузки самой операционной системы (еще в установочной фазе) производится быстрое преобразование раздела в NTFS; так что пользователь ничего и не замечает, кроме странного "ограничения" на размер NTFS при установке. Теперь что касается самой NTFS. 
 
Структура раздела хранения файлов.

Примерно все это выглядит так: 
 
Свободное место диска, однако, включает в себя всё физически свободное 
место - незаполненные куски 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 будет более удачным выбором при любых других условиях.