Реферат: Файловые системы, их виды

СОДЕРЖАНИЕ

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’а, удалиться сам монтируемы