Безопасность в файловой системе NTFS

СОДЕРЖАНИЕ Введение Часть 1. Физическая структура NTFS Лирическое отступление Структура раздела – общий взгляд
MFT и его структура Метафайлы Файлы и потоки Каталоги Сжатие Безопасность Hard Links Symbolic Links (NT5, NT5.1) Шифрование (NT5, NT5.1) Часть 2. Особенности дефрагментации NTFS Средства решения? Часть 3. Что выбрать? Часть 4. Журналирование NTFS Принцип Журналируемые операции Отложенная запись и контрольные точки журналирования Проблемы отложенного журналирования: концепция дублирования информации Допущения, обеспечивающие надежность Часть 5. Программный RAID RAID 0 (параллельные диски) RAID 1 (зеркальные диски) RAID 5 (параллельные диски с четностью) Допущения, обеспечивающие надежность Часть 6. Стратегия восстановления томов NTFS Часть 7. Быстродействие FAT и NTFS 1.Теория Поиск данных файла Поиск свободного дискового пространства Работа с каталогами и файлами 2.Практика Объем оперативной памяти (кэширование) Быстродействие дискового накопителя Размер кластера Другие соображения 3.Выводы Список литературы Введение Операционные системы Microsoft семейства Windows NT нельзя представить без файловой системы NTFS - одной из самых сложных и удачных из существующих на данный момент файловых систем. Ниже рассказывается об особенностях и недостатках этой системы, на каких принципах основана организация информации, как поддерживать систему в стабильном состоянии, какие возможности предлагает NTFS как их можно использовать обычному пользователю и производится сравнение двух файловых систем, таких как NTFS и FAT по быстродействию. Часть 1. Физическая структура NTFS Начнем с общих фактов. Раздел NTFS, теоретически, может быть почти какого угодно размера. Предел, конечно, есть, но я даже не буду указывать его, так как его с запасом хватит на последующие сто лет развития вычислительной техники - при любых темпах роста. Как обстоит с этим дело на практике? Почти так же. Максимальный размер раздела NTFS в данный момент ограничен лишь размерами жестких дисков. В NT4, правда, будут возникать проблемы при попытке установки на раздел, если хоть какая-нибудь его часть отступает более чем на 8 Гб от физического начала диска, но эта проблема касается лишь загрузочного раздела. Лирическое отступление Метод установки NT4.0 на пустой диск довольно оригинален и может навести на неправильные мысли о возможностях NTFS. Если вы укажете программе установки, что желаете отформатировать диск в NTFS, максимальный размер, который она вам предложит, будет всего 4 ГБ. Почему так мало, если размер раздела NTFS на самом деле практически неограничен? Дело в том, что установочная секция просто не знает этой файловой системы. Программа установки форматирует этот диск в обычный FAT, максимальный размер которого в NT составляет 4 ГБ (с использованием не совсем стандартного огромного кластера 64 КБ), и на этот FAT устанавливает NT. А вот уже в процессе первой загрузки самой операционной системы (еще в установочной фазе) производится быстрое преобразование раздела в NTFS; так что пользователь ничего и не замечает, кроме странного "ограничения" размера NTFS при установке. Структура раздела – общий взгляд Как и любая другая система, NTFS делит все полезное место на кластеры - блоки данных, используемые одновременно. NTFS поддерживает почти любые размеры кластеров - от 512 байт до 64 КБ, неким стандартом же считается кластер размером 4 КБ. Никаких аномалий кластерной структуры NTFS не имеет, поэтому на эту, в общем-то, довольно банальную тему, сказать особо нечего. Диск NTFS условно делится на две части. Первые 12% диска отводятся под так называемую MFT зону - пространство, в которое растет метафайл MFT (об этом ниже). Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой - это делается для того, чтобы самый главный, служебный файл (MFT) не фрагментировался при своем росте. Остальные 88% диска представляют собой обычное пространство для хранения файлов. Свободное место диска, однако, включает в себя всё физически свободное место - незаполненные куски MFT-зоны туда тоже включаются. Механизм использования MFT-зоны таков: когда файлы уже нельзя записывать в обычное пространство, MFT-зона просто сокращается (в текущих версиях операционных систем ровно в два раза), освобождая таким образом место для записи файлов. При освобождении места в обычной области MFT зона может снова расширится. При этом не исключена ситуация, когда в этой зоне остались и обычные файлы: никакой аномалии тут нет. Что ж, система старалась оставить её свободной, но ничего не получилось. Метафайл MFT все-таки может фрагментироваться, хоть это и было бы нежелательно. MFT и его структура Файловая система NTFS представляет собой выдающееся достижение структуризации: каждый элемент системы представляет собой файл - даже служебная информация. Самый главный файл на NTFS называется MFT, или Master File Table - общая таблица файлов. Именно он размещается в MFT зоне и представляет собой централизованный каталог всех остальных файлов диска, и, как не парадоксально, себя самого. MFT поделен на записи фиксированного размера (обычно 1 КБ), и каждая запись соответствует какому либо файлу (в общем смысле этого слова). Первые 16 файлов носят служебный характер и недоступны операционной системе - они называются метафайлами, причем самый первый метафайл - сам MFT. Эти первые 16 элементов MFT - единственная часть диска, имеющая фиксированное положение. Интересно, что вторая копия первых трех записей, для надежности - они очень важны - хранится ровно посередине диска. Остальной MFT-файл может располагаться, как и любой другой файл, в произвольных местах диска - восстановить его положение можно с помощью его самого, "зацепившись" за самую основу - за первый элемент MFT. Метафайлы Первые 16 файлов NTFS (метафайлы) носят служебный характер. Каждый из них отвечает за какой-либо аспект работы системы. Преимущество настолько модульного подхода заключается в поразительной гибкости - например, на FAT-е физическое повреждение в самой области FAT фатально для функционирования всего диска, а NTFS может сместить, даже фрагментировать по диску, все свои служебные области, обойдя любые неисправности поверхности – конечно кроме первых 16 элементов MFT. Метафайлы находятся в корневом каталоге NTFS диска - они начинаются с символа-имени "$", хотя получить какую-либо информацию о них стандартными средствами сложно. Любопытно, что и для этих файлов указан вполне реальный размер - можно узнать, например, сколько операционная система тратит на каталогизацию всего вашего диска, просмотрев размер файла $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 и Windows XP (самая правая закладка в свойствах файла, просматриваемых из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами: наблюдаемый размер файла - это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длинны, при стирании которого освободится 1 ГБ дискового пространства, - просто потому, что какая-нибудь хитрая программа или технология прикрепила к нему дополнительный поток (альтернативные данные) гигабайтового размера. Но на самом деле в текущий момент потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны. Просто имейте в виду, что файл на NTFS - это более глубокое и глобальное понятие, чем можно себе вообразить просто просматривая каталоги диска. Ну и напоследок: имя файла может содержать любые символы, включая полый набор национальных алфавитов, так как данные представлены в Unicode - в 16-битном представлении, которое дает 65535 различных символов. Максимальная длина имени файла - 255 символов. Каталоги Каталог на NTFS представляет собой специфический файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение данных на диске. Файл каталога поделен на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент MFT, который в свою очередь предоставляет полную информацию об элементе каталога. Внутренняя структура каталога представляет собой бинарное дерево. Вот что это означает: для поиска файла с данным именем в линейном каталоге, таком, например, как у FAT-а, операционной системе приходится просматривать все элементы каталога, до тех пор пока она не найдет необходимый. Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся наиболее быстрым способом - с помощью получения двухзначных ответов на запросы о расположении файла. Запрос, на который бинарное дерево способно дать ответ, таков: в какой группе, относительно данного элемента, находится искомое имя - выше или ниже? Начинается такой запрос с центрального элемента списка, и каждый ответ сокращает область поиска в среднем в два раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на запрос осуществляется элементарным способом - сравнением начальных букв. Область поиска, суженная в два раза, исследуется аналогичным образом, начиная опять же с центрального элемента. Вывод - для поиска одного файла среди 1000, например, FAT придется осуществить в среднем 500 сравнений (наиболее вероятно, что файл будет найден посередине выполнения поиска), а системе на основе дерева - всего около 12-ти (2^10 = 1024). Экономия времени поиска налицо. Не стоит, однако думать, что в традиционных системах (FAT) всё так запущено: во-первых, поддержание списка файлов в виде бинарного дерева довольно трудоёмкая операция, а во-вторых - даже FAT в исполнении современной системы (Windows 2000, Windows XP или Windows 98) использует сходную оптимизацию поиска. Хочется также развеять распространенное заблуждение о том, что добавлять файл в каталог в виде дерева сложнее, чем в линейный каталог: это примерно одинаковые по времени операции. Дело в том, что для добавления файла в каталог, необходимо сначала убедится, что файла с таким именем в этом каталоге еще нет - и вот тут-то в линейной системе возникают трудности с поиском файла, описанные выше, которые с лихвой компенсируют саму простоту добавления файла в каталог. Какую информацию можно получить, просто прочитав файл каталога? Ровно то же, что выдает команда dir. Для выполнения простейшей навигации по диску не нужно обращаться в MFT за каждым файлом, надо лишь считывать самую общую информацию о файлах из файлов каталогов. Главный каталог диска - корневой - ничем не отличается от обычных каталогов, кроме специальной ссылки на него из начала метафайла MFT.
Сжатие Файлы NTFS имеют один довольно полезный атрибут - "сжатый". Дело в том, что NTFS имеет встроенную поддержку сжатия дисков - то, для чего раньше приходилось использовать Stacker или DoubleSpace. Любой файл или каталог в индивидуальном порядке может храниться на диске в сжатом виде - этот процесс совершенно прозрачен для приложений. Сжатие файлов имеет очень высокую скорость и только одно большое отрицательное свойство - огромная виртуальная фрагментация сжатых файлов, которая, правда, никому особо не мешает. Сжатие осуществляется блоками по 16 кластеров и использует так называемые "виртуальные кластеры" - опять же предельно гибкое решение, позволяющее добиться интересных эффектов - например, половина файла может быть сжата, а половина - нет. Это достигается благодаря тому, что хранение информации о компрессированности определенных фрагментов очень похоже на обычную фрагментацию файлов: например, типичная запись физической раскладки для реального, несжатого, файла:
кластеры файла с 1-го по 43-й хранятся в кластерах диска начиная с 400-го кластеры файла с 44-го по 52-й хранятся в кластерах диска начиная с 8530-го . Физическая раскладка типичного сжатого файла: кластеры файла с 1-го по 9-й хранятся в кластерах диска начиная с 400-го кластеры файла с 10-го по 16-й нигде не хранятся кластеры файла с 17-го по 18-й хранятся в кластерах диска начиная с 409-го кластеры файла с 19 по 36-й нигде не хранятся Видно, что сжатый файл имеет "виртуальные" кластеры, реальной информации в которых нет. Как только система видит такие виртуальные кластеры, она тут же понимает, что данные предыдущего блока, кратного 16-ти, должны быть разжаты, а получившиеся данные как раз заполнят виртуальные кластеры - вот, по сути, и весь алгоритм. Безопасность NTFS содержит множество средств разграничения прав объектов - есть мнение, что это самая совершенная файловая система из всех ныне существующих. В теории это, без сомнения, так, но в текущих реализациях, к сожалению, система прав достаточно далека от идеала и представляет собой хоть и жесткий, но не всегда логичный набор характеристик. Права, назначаемые любому объекту и однозначно соблюдаемые системой, эволюционируют - крупные изменения, и дополнения прав осуществлялись уже несколько раз и к Windows 2000 все-таки они пришли к достаточно разумному набору. Права файловой системы NTFS неразрывно связаны с самой системой - то есть они, вообще говоря, необязательны к соблюдению другой системой, если ей дать физический доступ к диску. Для предотвращения физического доступа в Windows 2000 (NT5) и Windows XP (NT5.1) всё же ввели стандартную возможность (об этом см. ниже). Система прав в своем текущем состоянии достаточно сложна (эта тема описана в книгах по сетевой архитектуре NT, более чем подробно). На этом описание строение файловой системы можно закончить, осталось описать лишь некоторое количество просто практичных или оригинальных вещей. Hard Links Эта штука была в NTFS с незапамятных времен, но использовалась очень редко - и тем не менее: Hard Link - это когда один и тот же файл имеет два имени (несколько указателей файла-каталога или разных каталогов указывают на одну и ту же MFT запись). Допустим, один и тот же файл имеет имена 1.txt и 2.txt: если пользователь сотрет файл 1, останется файл 2. Если сотрет 2 - останется файл 1, то есть оба имени, с момента создания, совершенно равноправны. Файл физически стирается лишь тогда, когда будет удалено его последнее имя. SymbolicLinks (NT5, NT5.1) Гораздо более практичная возможность, позволяющая делать виртуальные каталоги - ровно так же, как и виртуальные диски командой subst в DOSе. Применения достаточно разнообразны: во-первых, упрощение системы каталогов. Если вам не нравится каталог Documents and settings\Administrator\Documents, вы можете прилинковать его в корневой каталог - система будет по-прежнему общаться с каталогом с дремучим путем, а вы - с гораздо более коротким именем, полностью ему эквивалентным. Для создания таких связей можно воспользоваться программой junction, которую написал известный специалист Mark Russinovich (http://www.sysinternals.com/). Программа работает только в NT5 (Windows 2000) и NT5.1 (Windows XP), как и сама возможность. Для удаления связи можно воспользоваться стандартной командой rd. ВНИМАНИЕ: Попытка удаления связи с помощью проводника или других файловых менеджеров, не понимающих виртуальную природу каталога (например, FAR), приведет к удалению данных, на которые указывает ссылка! Будьте осторожны. Шифрование (NT5, NT5.1) Полезная возможность для людей, которые беспокоятся за свои секреты - каждый файл или каталог может также быть зашифрован, что не даст возможность прочесть его другой установленной NT. В сочетании со стандартным и практически непрошибаемым паролем на загрузку самой системы, эта возможность обеспечивает достаточную безопасность для большинства применений избранных вами важных данных. Часть 2. Особенности дефрагментации 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 - [назад] - 14 - 14 - 14 1 - 1 - 1 -1 - 1 . Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более крупные куски свободного пространства. Вспомните сжатые файлы, - при активной перезаписи больших объемов сжатой информации на NTFS образуется гигантское количество "дырок" из-за перераспределения на диске сжатых объемов. Если какой-либо участок файла стал сжиматься лучше или хуже, его приходится либо изымать из непрерывной цепочки и размещать в другом месте, либо стягивать в объеме, оставляя за собой дырку. Смысл в сего этого вступления в пояснении того простого факта, что никак нельзя сказать, что NTFS препятствует фрагментации файлов. Наоборот, она с радостью их фрагментирует. Фрагментация NTFS через пол года работы доведет до искреннего удивления любого человека, знакомого с работой файловой системой. Поэтому периодически приходится запускать "дефрагментатор". Но на этом все наши проблемы не заканчиваются, а, увы, только начинаются . Средства решения? В NT существует стандартная API дефрагментация, обладающая интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16-ти кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16-ти кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия: В свободную дырку менее 16-ти кластеров нельзя ничего переместить (кроме сжатых файлов, но это неинтересные в данный момент тонкости). Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) "временно занятое пространство", дополняющее его по размеру до кратности 16-ти кластерам. При попытке как-то неправильно ("не кратно 16-ти") переместить файл, результат часто непредсказуем. Что-то округляется, что-то просто не перемещается . Тем не менее, всё пространство действия щедро рассыпается "временно занятым пространством". "Временно занятое пространство" служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то пол минуты. Тем не менее, логично было бы использовать это API, раз он есть. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, состоит из следующих фаз (не обязательно в этом порядке): Вынимание файлов из MFT зоны. Не специально - просто обратно туда их положить не представляется возможным. Безобидная фаза, и даже в чем-то полезная. Дефрагментация файлов - безусловно, полезный процесс, правда, несколько, осложняемый ограничениями кратности перемещений - файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму. Дефрагментация MFT, файла виртуальной памяти (pagefile.sys) и каталогов - возможна через API, только в Windows 2000 и Windows XP, иначе - при перезагрузке, отдельным процессом, как в старом Diskeeper-е. Складывание файлов ближе к началу - так называемая дефрагментация свободного места. Вот это - воистину страшный процесс . Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но более слабой фрагментацией всех файлов на диске. Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то напрямую - Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag и т.д. - не упоминают этого самого главного, принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере, уж точно не афишируется на каждом шагу. Speeddisk - единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 КБ, а SpeedDisk и это может. К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и соответственно, плодит дырки Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации "новоприбывающих" файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложились исторически. Часть 3. Что выбрать? Любая из представленных ныне файловых систем уходит своими корнями в глубокое прошлое - еще к 80-м годам. Да, NTFS, как это не странно - очень старая система! Дело в том, что долгое время персональные компьютеры пользовались лишь операционной системой DOS, которой и обязана своим появлением FAT-а. Но параллельно разрабатывались и тихо существовали системы, нацеленные на будущее. Две таких системы, получившие всё же широкое признание - NTFS, созданная для операционной системы Windows NT 3.1 еще в незапамятные времена, и HPFS - верная спутница OS/2. Внедрение новых систем шло трудно - еще в 1995 году, с выходом Windows 95, ни у кого не было и мыслей о том, что нужно что-то менять. FAT получил второе дыхание посредством налепленной сверху заплатки "длинные имена", реализация которых там хоть и близка к идеально возможной без изменения системы, но всё же довольно бестолкова. Но в последующие годы необходимость перемен назрела окончательно, поскольку естественные ограничения FAT-а стали давать о себе знать. FAT32, появившаяся в Windows 95 OSR2, просто сдвинула рамки - не изменив сути системы, которая просто не дает возможности организовать эффективную работу с большим количеством данных.
HPFS (High Performance File System), активно применяемая до сих пор пользователями OS/2, показала себя достаточно удачной системой, но и она имела существенные недостатки - полное отсутствие средств автоматической восстанавливаемости, излишнюю сложность организации данных и невысокую гибкость.
NTFS же долго не могла завоевать персональные компьютеры из-за того, что для организации эффективной работы с её структурами данных требовались значительные объемы памяти. Системы с 4 или 8 МБ (стандарт 95-96 годов) были просто неспособны, получить хоть какой-либо плюс от NTFS, поэтому за ней закрепилась не очень правильная репутация медленной и громоздкой системы. На самом деле это не соответствует действительности - современные компьютерные системы с памятью более 64 МБ получают просто огромный прирост производительности от использования NTFS. В данной таблице сведены воедино все существенные плюсы и минусы распространенных в наше время систем, таких как FAT, FAT32 и NTFS. Вряд ли разумно обсуждать другие системы, так как в настоящее время 97% пользователей делают выбор между Windows 98, Windows NT4.0, Windows 2000 (NT5.0) и Windows XP (NT5.1), а других вариантов там просто нет. (таблица на следующей странице) FAT FAT32 NTFS Поддерживающие системы DOS, Windows9Х, NT всех версий Windows 98, NT5 NT4, NT5, NT5.1 Максимальный размер тома 2 ГБ практически неограничен практически неограничен Максимальное число файлов на томе примерно 65 тысяч практически неограниченно практически не ограничено Имена файлов с поддержкой длинных имен - 255 символов, системный набор символов с поддержкой длинных имен - 255 символов, системный набор символов 255 символов, любые символы любых алфавитов (65000 разных начертаний) Возможные атрибуты файла базовый набор базовый набор всё, что придет в голову производителям программного обеспечения Безопасность Нет нет да (начиная с NT5.0 и выше, встроена возможность физического шифрования данных) Сжатие Нет нет да Устойчивость к сбоям Средняя (система слишком проста, и поэтому ломаться особо нечему) плохая (средства оптимизации по скорости привели к появлению слабых по надежности мест) полная - автоматическое восстановление системы при любых сбоях (не считая физические ошибки записи, когда пишется одно, а на самом деле записывается другое) Экономичность минимальная (огромные размеры кластеров на больших дисках) средняя (улучшена за счет уменьшения размеров кластеров) максимальная (очень эффективная и разнообразная система хранения данных) Быстродействие высокое для малого числа файлов, но быстро уменьшается с появлением большого количества файлов в каталогах; результат - для слабо заполненных дисков - максимальное, для заполненных - плохое полностью аналогично FAT, но на дисках большого размера (десятки гигабайт) начинаются серьезные проблемы с общей организацией данных система не очень эффективна для малых и простых разделов (до 1 ГБ), но работа с огромными массивами данных и внушительными каталогами организована как нельзя более эффективно и очень сильно превосходит по скорости другие системы Хотелось бы сказать, что если ваша операционная система - NT (Windows 2000, Windows XP), то использовать какую-либо файловую систему, отличную от NTFS - значит существенно ограничивать свое удобство и гибкость работы самой операционной системы. NT, а особенно Windows 2000 или Windows XP, составляет с NTFS как бы две части единого целого - множество полезных возможностей NT напрямую завязано на физическую и логическую структуру файловой системы, и использовать там FAT или FAT32 имеет смысл лишь для совместимости - если у вас стоит задача читать эти диски из каких-либо других систем. Часть 4. Журналирование NTFS Описание того простого факта, что NTFS является журналируемой системой, повергло многочисленных поклонников других файловых и операционных систем в искреннее возмущение. Многие, называли NTFS системой с квази-журналированием или даже без журналирования вообще, ставя в противовес многочисленные файловые системы Unix. Упоминаются также фатальные сбои NTFS, восстановление после которых не удалось - данные были потеряны. В данной части будет объяснена философия журналирования и средств защиты от сбоев NTFS, а также пояснены причины появления фатальных сбоев. Я постараюсь оправдать подход корпорации Microsoft, которая сделала всё именно так, как сделала - по крайней мере, я изложу причины реализованных технологических решений и те компромиссы, на которые пришлось пойти коллективу разработчиков NTFS. Принцип NTFS - отказоустойчивая система, которая вполне может привести себя в корректное состояние при практически любых реальных сбоях. Любая современная файловая система основана на таком понятии, как транзакция - действие, совершаемое целиком и корректно или не совершаемое вообще. У NTFS просто не бывает промежуточных (ошибочных или некорректных) состояний - квант изменения данных не может быть поделен на состояния до и после сбоя, принося разрушения и путаницу - он либо совершен, либо отменен. Пример 1: осуществляется запись данных на диск. Вдруг выясняется, что в то место, куда мы только что решили записать очередную порцию данных, запись не удалась - физическое повреждение поверхности. Поведение NTFS в этом случае довольно логично: транзакция записи откатывается целиком - система осознает, что запись не произведена. Пространство помечается как сбойное, а данные записываются в другое место - начинается новая транзакция.
Пример 2: более сложный случай - идет запись данных на диск. Вдруг, - отключается питание и система перезагружается. На какой фазе остановилась запись, где есть данные, а где чушь? На помощь приходит другой механизм системы - журнал транзакций. Дело в том, что система, уловив операцию записи на диск, пометила в метафайле $LogFile это состояние. При перезагрузке это файл изучается на предмет наличия незавершенных транзакций, которые были прерваны аварийной ситуацией и результат которых непредсказуем - все эти транзакции отменяются: пространство, в которое осуществлялась запись, помечается снова как свободное, индексы и элементы MFT приводятся в с состояние, в котором они были до сбоя, и система в целом остается стабильна. Ну а если ошибка произошла при записи в журнал? Тоже ничего страшного: транзакция либо еще и не начиналась (идет только попытка записать намерения её произвести), либо уже закончилась - то есть идет попытка записать, что транзакция на самом деле уже выполнена. В последнем случае при следующей загрузке система сама вполне разберется, что на самом деле всё и так записано корректно, и не обратит внимания на "незаконченную" транзакцию.
И все-таки помните, что журналирование - не абсолютная панацея, а лишь средство существенного сокращения числа ошибок и сбоев системы. Вряд ли рядовой пользователь NTFS хоть когда-нибудь заметит ошибку системы или вынужден будет запускать программу проверки диска (chkdsk) - опыт показывает, что NTFS восстанавливается в полностью корректное состояние даже при сбоях в очень загруженные дисковой активностью моменты. Вы можете даже оптимизировать диск и в самый разгар этого процесса нажать reset - вероятность потерь данных даже в этом случае будет очень низка. Важно понимать, однако, что система восстановления NTFS гарантирует корректность файловой системы, а не ваших данных. Если вы производили запись на диск, и при этом произошел сбой, то ваши данные могут и не записаться. Чудес не бывает. Журналируемые операции Прежде всего, хотелось бы рассказать о том, какие именно операции журналируются. Совершенно очевидно, что полный undo-файл, способный откатить абсолютно все операции - невозможен как с точки зрения быстродействия, так и с точки зрения здравого смысла. Да, такое журналирование дало бы возможность восстановить большее число данных - например, при осуществлении перезаписи трех мегабайт в середине файла мы могли бы сначала сохранить новые данные в логе, затем переписать туда же предыдущие три мегабайта файла, и уж только затем осуществлять операции с реальными данными. Такой подход гарантировал бы полную определенность с судьбой информации - мы всегда смогли бы понять, какая часть данных уже записалась на диск, а какая находится в исходном, не обновленном состоянии. Он имеет всего один скромный недостаток - небольшая накладочка по быстродействию: для записи на диск трех мегабайт мы вынуждены будем осуществить разнообразные дисковые операции на объем в три раза больший - девять мегабайт. Да, полное журналирование также применяется - но в основном при работе с базами данных. Если вы желаете обеспечить полное журналирование каких-либо данных, то можете установить MS SQL или даже Oracle, который вообще не будет пользоваться средствами какой либо файловой системы и обеспечит сохранность ваших данных в любых разумных условиях. Сторонникам же полного журналирования файловой системы я могу ответить одно: решение сократить быстродействие операций записи в три раза, на мой взгляд, является слишком смелым для обязательного применения - и на домашних компьютерах, и на серверах. Подход разработчиков NTFS был принципиально иным. Главный девиз был, видимо, не "надежность любой ценой", а "неизменность быстродействия". Журналирование просто не должно было помешать работе файловой системы. Первый логичный шаг - отменить полное журналирование как абсолютно неприемлемое с точки зрения быстродействия. В NTFS применяется журналирование логических структур, а не данных пользователя - отсюда и идет фраза, что сохранность данных не гарантируется, но, тем не менее, корректное состояние самой системы будет поддерживаться. То, что NTFS не журналирует данные файлов, приводит на практике к одному варианту потери данных - в том же гипотетическом случае записи трех мегабайт, в случае сбоя в процессе записи никогда уже не удастся установить, какая часть данных записалась, а какая осталась неизменна. Операции, которые, тем не менее, журналируются системой - это операции со структурами самой системы, то есть с файлами и каталогами: добавление файлов, переименование, перенос, создание и удаление (высвобождение дискового пространства). Журналируются также и операции дефрагментации - то есть перемещения фрагментов файлов. Одним словом, все логические операции журналированы. Отложенная запись и контрольные точки журналирования Известно, что любая современная система для ускорения файловых операций вынуждена использовать кэширование, в том числе - кэширование операций записи. Так называемая отложенная запись - принцип кэширования, при котором данные, предназначенные для записи на диск, некоторое время сохраняются в КЭШе и лишь в свободное от других занятий время сохраняются физически. Отложенная запись существенно повышает эффективность дисковых операций, так как такое кэширование группирует множество операций в одну - это особенно эффективно, если запись производится в компактные участки диска. Еще один плюс отложенной записи - не мешать более нужным операциям чтения, и осуществлять запись только тогда, когда система свободна и ей не требуется доступ к диску для других нужд. Как согласовать отложенную запись с журналированием? Это довольно сложный вопрос, так как откладывание записи делает возможным потерю тех данных, которые находились в очереди на физическую запись и не успели записаться на диск до сбоя. Самое неприятное здесь даже не потеря данных, а то, что происходит рассогласование времени записи: какие-то служебные области могут быть обновлены, а какие-то смежные по смыслу - еще нет, так как их обновление могло отложиться еще на пару секунд, и не состоятся из-за сбоя. NTFS справляется с этими проблемами с помощью смысловой интеграции операций отложенной записи и ведения журнала. При попытке начать журналируемую операцию в лог тут же записывается намерение - например, стереть файл. Это случается без задержек - на этом этапе отложенная запись не работает: это плата за присутствие журналирования, которой нельзя избежать. Но вот все остальные операции уже идут в задержанном режиме - то есть они могут состояться частично (могут еще в придачу и не в том порядке) или не состоятся вообще. Единственная задержанная операция, работа которой несколько отличается от простой записи - запись в лог об удачном завершении предыдущих транзакций, так называемая контрольная точка. Через определенные промежутки времени - обычно через каждые несколько секунд - система в обязательном порядке сбрасывает абсолютно все задержанные операции на диск. После произведения этой операции в журнал записывается простейшая запись - контрольная точка - которая говорит о том, что все предыдущие операции выполнены корректно на всех уровнях - как на логическом, так и на физическом.
Такой режим работы с помощью записей и контрольных точек - с одной стороны, по прежнему гарантирует полностью корректную работу журналирования, с другой стороны практически не приводит к замедлению работы (остановка контрольных точек производится мгновенно), а запись в журнал о начале операции соответствует по трудозатратам записи самих данных без отложенного кэширования. Реальная же запись, осуществляемая позже, в подавляющем числе случаев не мешает никаким операциям и не идет в ущерб производительности системы.
Проблемы отложенного журналирования: концепция дублирования информации Вся вышеописанная теория достаточно хороша, но, тем не менее, способна вызвать очень неприятные последствия, если не учесть еще нескольких вещей, о которых и пойдет речь. Рассмотрим такой случай: мы стираем файл. Журнал получил запись - "файл N стирается". Затем запаздывающему КЭШу стало угодно осуществить сначала физическую пометку о том, что место, занимаемое файлом, освободилось, а уж только затем удалить файл из физических структур MFT и каталога. Допустим, диск находится в активной работе, и на освободившееся место тут же записывается другой файл. В этот момент происходит сбой. Система, загружаясь, исследует журнал и видит незавершенную операцию "файл N стирается" - вернее, как было описано выше, не незавершенную, а просто операцию, контрольная точка после которой отсутствует, что автоматически говорит о её незавершенности. Следующая фаза была бы "откат операции" - то есть восстановление файла. Одна незадача - место, физически занимаемое файлом, содержит уже другие данные. Для недопущения таких ситуаций система, желающая ограничиться логическим журналированием, вынуждена применять принцип "временно занятого места". Пространство, освобожденное каким-либо объектом или записью о нем, не объявляется свободным до тех пор, пока физически не завершились все операции с логическими структурами. Данный механизм в NTFS, по-видимому, не синхронизирован даже с проставлением контрольных точек, так как типичное время освобождения временно занятого места - около 30 секунд, точки же идут чаще. Данный механизм применяется не только при стирании файла, но и при самых разных операциях: принцип журналирования - объект, убранный или перемещенный на новое место, должен иметь возможность корректно откатить своё "отбытие" - то есть данные, на которые ссылаются логические структуры удаляемого или перемещаемого объекта, необходимо еще на некоторое время зарезервировать как занятое место (диска/каталога). Это еще один шаг NTFS к полному журналированию, где специфическим журналом файловой информации служат сами данные освобождаемых областей, не уничтожаемые физически. Допущения, обеспечивающие надежность Всё так замечательно, скажете вы - но почему же тогда разделы NTFS всё же летят? Сейчас я постараюсь объяснить принципы, которые приводит к тому, что вышеописанная модель сможет обеспечить полную восстанавливаемость логических структур. Жесткий диск, в штатном режиме, должен записать именно то и именно туда, что и куда ему сказано было записать операционной системой. Данный принцип нарушается в случае, если система имеет ненадежный шлейф, процессор, память или контроллер - и это самая распространенная причина сбоев NTFS. Вам поможет: не разогнанный процессор, дорогая (качественная) память, хорошая материнская плата и протокол UDMA, обеспечивающий контроль и восстановление ошибок на участке контроллер-диск. Жесткий диск, в случае аварии, отключения питания или получения от контроллера сигнала "сброс" (в случае внезапной перезагрузки материнской платы) обязан корректно завершить запись данных текущего физического сектора, если таковая производилась в момент происшедшего сбоя. Промежуточное состояние сектора не допускается. Вам помогут современные винчестеры, которые могут осуществить данную операцию даже в случае полного пропадания питания - у них хватит буферизированной энергии в конденсаторах, и их логика рассчитана на корректное поведение в случае отказа питания при записи. Диск обязан мгновенно осуществить запись данных, отправленных с флагом "не кэшировать". Дело в том, что многие современные диски или контроллеры обеспечивают задержанную запись. Метафайлы NTFS обновляются в режиме "писать сразу", и контроллер/диск обязан выполнять это требование. Жесткий диск обязан обеспечить чтение именно тех данных, которые были записаны. В случае невозможности прочесть данные выдается сигнал "ошибка". Диск не имеет права возвращать ошибочные данные (возможно, лишь частично некорректные) без сигнала об ошибке. Все современные жесткие диски имеют контрольные суммы секторов и жестко следуют этой логике поведения. Четкое выполнение этих требований полностью гарантирует надежную работу NTFS. Структура файловой системы не будет содержать существенных ошибок даже после сбоя. Некоторые несущественные ошибки всё же появляются из-за того, что логика журналирования часто пытается завершить недоделанные операции - например, то же удаление файла - тогда как полную надежность обеспечивал бы только безусловный откат всего, что находится после последней контрольной точки. Малые несоответствия, рождающиеся из этих попыток, относятся к избыточной информации системы безопасности, не представляют никакой реальной опасности для данных - они действительно незначительны. Суть этих несоответствий чаще всего заключается в том, что на диске остаются "лишние" данные о тех режимах доступов, которые уже не требуются системе. Их прочистка - дело сугубо повышения производительности, как, например, дефрагментация, поэтому их наличие не является на самом деле ошибкой. В случае же обнаружения серьезных, реальных, проблем драйвер сам установит флажок тома "грязный", что проинструктирует систему проверить том при следующем его монтировании. Я с большим сожалением должен сказать, что подавляющее большинство фатальных ошибок NTFS происходит по вине аппаратуры, не выполняющей эти элементарные требования. Понятно, что абсолютной надежности не бывает. Но Microsoft пошел по пути разделения труда - за надежность вашей аппаратуры корпорация ответственности не несет. Мой компьютер на 70% не попадает в список совместимого с Windows XP оборудования, и то же самое можно сказать про почти любую реальную машину, функционирующую на просторах бывшего СССР. Особенно это относится к любителям разгонять компьютеры. Запомните раз и навсегда: вероятность того, что вы угробите NTFS в первый же год работы на разогнанном 333 до 415 процессоре. Мне очень жаль, но это действительно так. От любых сбоев корректного компьютера NTFS защитит, но вот от записи случайных данных в "бут-сектор" (копия которого, кстати, хранится в самом конце раздела) и в MFT система просто не страхуется. Часть 5. Программный RAID
Журналирование NTFS, как уже указывалось ранее, ни в коей мере не гарантирует защиту от сбоев без потерь пользовательской информации. Между тем, NT предлагает несколько вариантов создания систем, где, в разумных условиях, гарантируется абсолютно всё. Можно также использовать большее число дисков для обеспечения не повышенной надежности, а, наоборот, повышенной скорости - или того и другого одновременно. О таких конфигурациях и пойдет речь в этой части статьи.
RAID (Redundant Array Of Inexpensive Disks) - избыточный массив недорогих дисков. Технология, заключающаяся в одновременном использовании нескольких дисковых устройств, для обеспечения характеристик надежности или скорости, отсутствующих у накопителей в отдельности. Windows NT поддерживает на программном уровне три уровня RAID (так называются стратегии работы дисковых массивов), краткие характеристики которых сведены в следующую таблицу на стр. 18. Быстродействие, по сравнению с обычными дисками Надежность Общее дисковое пространство RAID 0 Параллельные диски Существенное повышение производительности за счет дублирования дисков. Теоретически, в условиях некоторых (например, линейных) операций скорость чтения/записи, повышается во столько раз, сколько дисков задействовано в системе. Реально увеличение быстродействия меньше - процентов 50%-90% от этого числа, что всё равно очень существенно. Понижается - фатальный сбой одного из дисков вызовет потерю данных. Равно сумме объемов составляющих массив дисков RAID 1 Зеркальные диски Повышение надежности за счет дублирования информации. Скорость чтения теоретически повышается в число раз, соответствующее числу дисков. Реализованный в NT алгоритм не оптимален и приводит к более скромному увеличению быстродействия. Скорость записи снижается, особенно в случае не до конца многозадачных дисковых контроллеров. Потеря данных возможна лишь в случае отказа сразу всех дисков или повреждения одного и того же участка информации на всех дисках. Остается неизменным (увеличение доступного дискового пространства за счет добавочных дисков не происходит). RAID 5 Параллельные диски с четностью Комбинация RAID 1 и RAID 0 - более эффективное использование дополнительных дисков. Скорость чтения повышается аналогичным RAID 0 образом, но число дисков, влияющих на быстродействие, следует уменьшить на один, т.е. 3 диска RAID 5 обладают примерно такой же скоростью чтения, как и 2 диска RAID 0. Скорость записи выше, чем у каждого диска в отдельности, но в целом невысока. Потеря данных возможна при выходе из строя двух дисков набора. Выход из строя одного из дисков существенно снижает скорость работы всего массива и является, по сути, аварийной ситуацией, хоть и без потерь данных. Увеличивается. Потеря от суммарного дискового объема составляет объем одного диска. Например, 5 дисков по 10 ГБ дают RAID 5 объемом 40 ГБ. RAID 0 (параллельные диски) Данная стратегия направлена исключительно на повышение производительности. Несколько дисков хранят части дисковой структуры, которые собираются в один том лишь при наличии всех дисков массива. Простейшая реализация RAID 0 из двух, например, дисков - указание на то, что каждый первый сектор тома (или любой другой объем информации) расположен на физическом диске A, а каждый второй - на диске B. Такая жесткая стратегия дает возможность избежать каких-либо дополнительных структур для хранения информации о том, где, какие данные находятся. Скорость чтения, как и записи равны и зависят от числа дисков: Быстродействие операции по работе со случайно расположенными данными подчиняются следующей схеме: всё зависит от вероятности того, что диск, на который мы хотим записать очередную порцию информации, свободен и готов мгновенно выполнить наш запрос. Например, RAID 0 из двух дисков: при осуществлении операции одним из дисков и поступлении дополнительной команды на работу с дисковой системой вероятность того, что для выполнения команды нам придется тревожить свободный в данный момент диск, составляет 50% - это соответствует общему увеличению производительности случайных операций в 1,5 раза. Если же используется, к примеру, массив из десяти дисков, то вероятность какой-либо операции попасть на уже занятый накопитель составляет всего 10% - то есть производительность повышается в 9 раз. Любителям строгой теории вероятности хочу заметить, что при таких подсчетах не учитываются некоторые факторы реальной работы систем, но цифры, тем не менее, имеют именно такой порядок. Последовательные операции - чтение или запись последовательных участков - проходят практически всегда в n раз быстрее, чем на отдельном физическом диске, где n - число дисков в наборе. Это происходит потому, что вероятность в следующей операции попасть на свободный диск составляет 100% - ведь операции осуществляются последовательными блоками, которые равномерно раскидываются по дискам. В качестве некоторого вывода - RAID 0 в любом случае существенно повышает быстродействие линейных операций, а с увеличением количества дисков, входящих в набор, существенно повышается скорость работы и со случайными данными. Для эффективной работы с дисковой системой в режиме RAID 0 просто необходим многозадачный режим работы контроллера, а желательно даже разных контроллеров, обеспечивающих доступ к разным дискам. Обязательным условием такой работы на интерфейсах IDE являются Bus-Mastering драйвера. Windows 2000 и Windows XP имеют встроенные драйвера, автоматически включающие этот режим для всех распространенных IDE контроллеров, для NT4 же могут понадобится дополнительные драйвера или изменения ключей реестра. Надежность RAID 0 низка - отказ каждого диска является фатальным сбоем, точно так же, как и отказ накопителя в случае работы с обычными разделами. Вероятность сбоя системы в целом только повышается - чем больше дисков вы используете, тем выше вероятность отказа хоть одного из них и, соответственно, потери какой-то части данных тома. RAID 1 (зеркальные диски) Самый простой способ обеспечения безопасности данных - создать копию двух дисков. Запись осуществляется на оба диска сразу, что приводит к замедлению этого процесса, тогда как чтение - с того диска, который в данный момент свободен - если, конечно, система способна эффективно осуществить такое чтение (необходимо наличие Bus-Mastering). Реализованный в NT алгоритм, к сожалению, не совсем оптимален и приводит к более скромному увеличению быстродействия чтения.
Некоторая сложность работы RAID 1 в программном режиме заключается в том, что часто система не может быть до конца уверена в идентичности данных двух дисков. Операция сверки двух физических дисков после серьезного сбоя может затянуться на часы и быть очень некстати, поэтому использовать программный RAID 1 следует очень осторожно. Если вы решаетесь на увеличение дисковых массивов в несколько раз только ради надежности, возможно, вам стоит приобрести аппаратный RAID контроллер, который, к тому же, обеспечит замену вышедших из строя дисков прямо на ходу, и следит за синхронностью данных самостоятельно. В любом случае, даже полный отказ одного из дисков не приводит к потере данных, так как диски полностью зеркальны.
RAID 5 (параллельные диски с четностью) Данная стратегия является в настоящее время наиболее удачной и эффективной схемой работы RAID, состоящих из трех и более дисков. Информация дополняется так называемыми данными четности (parity), которые размещаются на другом физическом диске, нежели реальные данные, контролируемые этой информацией. Концепцию четности можно понять, например, так: допустим, у нас есть пять бит - например, набор {0, 1, 1, 0, 1}. Мы формируем еще бит - бит четности, шестой, по такому правилу - если число единиц в предыдущих пяти битах четно, он будет равен 1, если нет - 0. В нашем случае число единиц равняется трем, т.е. нечетному числу - наш набор дополнился числом 0 и превратился в {0, 1, 1, 0, 1, }. Допустим, набору данных причинен урон - {0, X, 1, 0, 1, }. С помощью правила, гласящего нам, что число единиц должно быть нечетно (последний бит), можно догадаться, что на месте X стояла единичка. Наш получившийся набор из шести бит (5 бит данных и 1 бит четности) избыточен и может грамотно скорректировать потерю любого из своих шести бит. Операции четности могут осуществляться не только с битами, но и с любыми объемами данных, что применяется в простейших алгоритмах восстановления данных. Возвращаемся к устройству RAID 5: (рисунок на следующей странице) На рисунке изображен массив из пяти дисков. Видно, что каждый диск хранит четыре (условные) части реальных данных и один блок данных четности. Блок четности - скажем, 0 parity - способен восстановить потерю одного из фрагментов - любого, но одного - среди A0, B0, C0 и D0. Все вместе они, в свою очередь, способны восстановить блок 0 parity. Из изображенной структуры RAID видно, что данные, необходимые для полного восстановления всего столбика - то есть информации любого диска в случае сбоя - находятся на других дисках. В этом и заключается восстановление - при записи данных на любой из дисков обновляется также блок четности другого диска, соответствующего текущему блоку (например, при записи в A2 обновляется еще и блок 2 parity). Чтение данных с исправного диска происходит без использования блоков четности, т.е. почти в том же режиме, в каком работает RAID 0. Быстродействие RAID 5 в том виде, в каком это реализовано в NT, даже немного выше, чем у RAID 0. Единственная накладка - в случае сбоя производительность массива снижается в огромное количество раз, так как при невозможности напрямую считать, например, D4, нужно будет восстанавливать данные этого блока с использованием всех других дисков одновременно - в нашем случае это будут блоки 4 parity, B4, C4 и E4. Как видно, выход из строя одного из дисков RAID 5 является хоть и не фатальной, но резко аварийной ситуацией - хотя бы из соображений быстродействия чтения с массива. Нетрудно догадаться также, откуда исходит требования как минимум трех дисков - в случае двух накопителей RAID 5 просто вырождается в RAID 1, так как единственный способ создать информацию четности списка из одного элемента - это тем или иным образом дублировать этот элемент. Допущения, обеспечивающие надежность RAID также не является панацеей от абсолютно всех бед аппаратуры. Я должен сказать очень неожиданную для некоторых людей вещь: на ненадежном (некорректном) компьютере испортить RAID почти так же легко, как и однодисковую систему. RAID совершенно не спасет в следующих случаях: Корректная запись некорректных данных, а также запись данных мимо ожидаемой области. К этому приводят, как и ранее, сбойная память, процессор, шлейф, контроллер, питание привода. Если диск не способен сообщить об ошибке чтения. RAID предназначен для минимизации ущерба всего в одном случае - при физическом отказе жесткого диска или, возможно, контроллера (в случае многоконтроллерного RAID). Отказы памяти, операционной системы, да и вообще всего остального RAID-ом не предусмотрены - точно так же, как и стратегией работы одиночной NTFS. И, напоследок, аксиома работы вышеописанных уровней RAID-а - любой сбой одного из дисков системы считается аварией, которую необходимо как можно быстрее ликвидировать. Особенно это относится к RAID 0 и RAID 5, штатная работа которых в условиях аварии одного из дисков практически невозможна. Более подробно с системой программных RAID Windows NT можно ознакомится в справке к программе (или модулю - в Windows 2000, Windows XP) Disk Administrator, где, собственно, и создаются эти типы дисков. Обращаю ваше внимание на то, что способности рабочих станций в создании и использовании RAID-ов сильно ограничены - рабочая станция NT4, к примеру, поддерживает только RAID 0 (параллельные диски), тогда как все описанные варианты работают лишь на серверных вариантах операционных систем. Часть 6. Стратегия восстановления томов NTFS Компьютер с NTFS не загружается. Что делать в этом случае? Как восстановить данные? Возможны два случая, действия в которых несколько отличаются друг от друга. К сожалению, простых стратегий восстановления NT и, соответственно, NTFS не существует - система достаточно сложна и не имеет простейших загрузочных средств, как, например, DOS или Windows 95/98. Первый вариант - система находилась на том же NTFS диске. Система просто-напросто перестала загружаться. Что же, тогда нам в 90% случаев предстоит поднимать не NTFS, а саму NT. Данная операция выходит далеко за рамки данной статьи, поэтому описываю лишь способ поставить рядом (на тот же NTFS раздел) еще одну систему NT, на которой можно будет в дальнейшем работать (и которая сможет считать ваши данные). Пользователи NT4 смогут поставить систему прямо на NTFS, каким-либо образом загрузившись в программу установки. Вам понадобится CD диск, который представляет собой корректный дистрибутив NT4. Такими свойствами, скорее всего, обладают диски, на которых NT4 находится в каталоге под именем i386, расположенном в корневом каталоге. Команда winnt /?, запущенная в этом каталоге, поможет вам выбрать ключи для создания трех загрузочных дискет, с которых можно будет запустить установку NT4 прямо на диск NTFS. Можно выбрать другой каталог установки - например, \winnt2, чтобы затем попытаться реанимировать вашу первую установленную NT4, если вы видите подходы к этой специфической проблеме, которая под силу только специалистам. Устанавливаемая заново операционная система корректно впишет себя в загрузочную область диска и нисколько не помешает вашему старому NT4.
В случае отсутствия CD в соответствующем формате (симптомы - надпись "вставьте диск с дистрибутивом NT4", не реагирующая на наличие вашего CD) - вам остается только поставить NT на какой-нибудь другой раздел, так как диск с NTFS недоступен из систем, отличных от NT.
Стоит учесть, что NT4 нельзя установить на NTFS, прошедшую преобразование в новый формат от Windows 2000/XP. NT4 всё же может считать такой NTFS, но только при наличии пакета обновления SP4 и выше. Пользователи Windows 2000 и Windows XP будут вынуждены найти загрузочный CD диск с Windows 2000/XP (таким является официальный дистрибутив), который сам предложит вам либо установить систему заново, либо попытаться восстановить старую установленную копию. Считать диск NTFS, с которым работал Windows 2000/XP, можно только самим Windows 2000/XP или NT4 с пакетом обновления SP4 и выше. Имейте в виду: восстановить какую-либо NT, не обладая диском аварийного восстановления (создается в NT4 командой rdisk /s, в Windows 2000/XP - программой резервного копирования), практически невозможно - это работа для специалиста. К слову говоря, даже при наличии диска восстановления, вам, скорее всего очень не понравится работа "восстановленной" системы, поэтому переустановка всей системы практически неизбежна. Если вы не являетесь опытным специалистом по NT, советую вам не пытаться пользоваться починяющими опциями программы установки NT, т.к. результат вас, скорее всего, крайне не удовлетворит. Попытка, конечно, не пытка, но комплекс операций по полноценной реанимации системы очень велик и мало где описан, поэтому вы останетесь в каком-то промежуточном, состоянии. Второй вариант - система сама по себе работает, но доступа к диску (не загрузочному, а какому-то другому) нет. Disk Administrator показывает для вашего раздела тип unknown (неизвестный). В подавляющем большинстве случаев это означает, что каким-то образом была осуществлена перезапись загрузочной области (boot sector-а) раздела, и NT действительно не догадывается, что это вообще NTFS. Операционная система NT на всякий случай хранит копию загрузочного сектора в конце раздела - если его скопировать обратно в надлежащее место, то в большинстве случаев диск опознается как NTFS и дальнейшее восстановление производится самостоятельно. Процесс вычисления правильных адресов достаточно сложен, поэтому я не буду его описывать. Для получения исчерпывающих инструкций для данного случая вам придется зайти на сайт http://msdn.microsoft.com/ и найти там статью Knowledge Base под номером Q153973 (скорее всего, вы сможете сделать это простым поиском) - после корректного следования этим инструкциям, система по крайней мере, распознается как NTFS, и дальнейшая судьба раздела зависит от внутренних средств восстановления NT, которые в таком случае возьмут его в оборот. Вам также поможет скромная на вид команда chkdsk, являющаяся неким ярлычком к системе внутреннего восстановления дисковых систем NT. Часть 7. Быстродействие FAT и NTFS В этой статье я попытаюсь дать оценку быстродействию файловых систем, используемых в операционных системах Windows 95/98/ME, а также Windows NT4.0/2000/XP. Статья не содержит графиков и результатов тестирований, так как эти результаты слишком сильно зависят от случая, методик тестирования и конкретных систем, и не имеют почти никакой связи с реальным положением дел. В этом материале вместо этого я постараюсь описать общие тенденции и соображения, связанные с производительностью файловых систем. Прочитав данный материал, вы получите информацию для размышлений и сможете, сами делать выводы, понять, какая система будет быстрее в тех или иных условиях, и почему. Возможно, некоторые факты помогут вам также оптимизировать быстродействие своей машины с точки зрения файловых систем, подскажут какие-то решения, которые приведут к повышению скорости работы всего компьютера. В данном обзоре упоминаются три системы - FAT (далее FAT16), FAT32 и NTFS, так как основной вопрос, стоящий перед пользователями Windows 2000/XP - это выбор между этими вариантами. Надеюсь, всё же, что изложенные соображения покажутся вам любопытными, и вы сможете сделать какие-то выводы и о тех системах, с которыми вам приходится работать. Данная статья состоит из множества разделов, каждый из которых посвящен какому-то одному вопросу быстродействия. Многие из этих разделов в определенных местах тесно переплетаются между собой. Если вы не нашли каких-то важных фактов в тексте - не спешите удивляться: скорее всего, вы встретите их позже. Прошу вас также не делать никаких поспешных выводов о недостатках и преимуществах той или иной системы, так как противоречий и подводных камней в этих рассуждениях очень и очень много. В конце я попытаюсь собрать воедино всё, что можно сказать о быстродействии систем в реальных условиях. 1. Теория Самое фундаментальное свойство любой файловой системы, влияющее на быстродействие всех дисковых операций - структура организации и хранения информации, т.е. то, как, собственно, устроена сама файловая система. Первый раздел - попытка анализа именно этого аспекта работы, т.е. физической работы со структурами и данными файловой системы. Теоретические рассуждения, в принципе, могут быть пропущены - те, кто интересуется лишь чисто практическими аспектами быстродействия файловых систем, могут обратиться сразу ко второй части статьи. Для начала хотелось бы заметить, что любая файловая система, так или иначе, хранит файлы. Доступ к данным файлов - основная и неотъемлемая часть работы с файловой системой, и поэтому, прежде всего, нужно сказать об этом пару слов. Любая файловая система хранит данные файлов в неких объемах - секторах, которые используются аппаратурой и драйвером как самая маленькая единица полезной информации диска. Размер сектора в подавляющем числе современных систем составляет 512 байт, и все файловые системы просто считывают эту информацию и передают её без какой либо обработки приложениям. Есть ли тут какие-то исключения? Практически нет. Если файл хранится в сжатом или закодированном виде - как это возможно, к примеру, в системе NTFS - то, конечно, на восстановление или расшифровку информации тратится время и ресурсы процессора. В остальных случаях чтение и запись самих данных файла осуществляется с одинаковой скоростью, какую бы файловую систему вы не использовали. Ниже обращается внимание на основные процессы, осуществляемые системой для доступа к файлам. Поиск данных файла Выяснение того, в каких областях диска хранится тот или иной фрагмент файла - процесс, который имеет принципиально разное воплощение в различных файловых системах. Имейте в виду, что это лишь поиск информации о местоположении файла - доступ к самим данным, фрагментированы они или нет, здесь уже не рассматривается, так как этот процесс совершенно одинаков для всех систем. Речь идет о тех "лишних" действиях, которые приходится выполнять системе перед доступом к реальным данным файлов.
На что влияет этот параметр: на скорость навигации по файлу (доступ к произвольному фрагменту файла). Любая работа с большими файлами данных и документов, если их размер - несколько мегабайт и более. Этот параметр показывает, насколько сильно сама файловая система страдает от фрагментации файлов.
NTFS способна обеспечить быстрый поиск фрагментов, поскольку вся информация хранится в нескольких очень компактных записях (типичный размер - несколько килобайт). Если файл очень сильно фрагментирован (содержит большое число фрагментов) - NTFS придется использовать много записей, что часто заставляет хранить их в разных местах. Лишние движения головок при поиске этих данных, в таком случае, приведут к сильному замедлению процесса поиска данных о местоположении файла. FAT32, из-за большой области самой таблицы размещения будет испытывать огромные трудности, если фрагменты файла разбросаны по всему диску. Дело в том, что FAT (File Allocation Table - таблица размещения файлов) представляет собой мини-образ диска, куда включен каждый его кластер. Для доступа к фрагменту файла в системе FAT16 и FAT32 приходится обращаться к соответствующей частичке FAT. Если файл, к примеру, расположен в трех фрагментах - в начале диска, в середине, и в конце - то в системе FAT нам придется обратиться к фрагменту FAT в его начале, в середине и в конце. В системе FAT16, где максимальный размер области FAT составляет 128 КБ, это не составит проблемы - вся область FAT просто хранится в памяти, или же считывается с диска целиком за один проход и буферизируется. FAT32 же, напротив, имеет типичный размер области FAT порядка сотен килобайт, а на больших дисках - даже несколько мегабайт. Если файл расположен в разных частях диска - это вынуждает систему совершать движения головок винчестера столько раз, сколько групп фрагментов в разных областях имеет файл, а это очень и очень сильно замедляет процесс поиска фрагментов файла. Вывод: Абсолютный лидер - FAT16, он никогда не заставит систему делать лишние дисковые операции для данной цели. Затем идет NTFS - эта система также не требует чтения лишней информации, по крайней мере, до тех пор, пока файл имеет разумное число фрагментов. FAT32 испытывает огромные трудности, вплоть до чтения лишних сотен килобайт из области FAT, если файл разбросан по разным областям диска. Работа с внушительными по размеру файлами на FAT32 в любом случае сопряжена с огромными трудностями - понять, в каком месте диска расположен тот или иной фрагмент файла, можно лишь изучив всю последовательность кластеров файла с самого начала, обрабатывая за один раз один кластер (через каждые 4 КБ файла в типичной системе). Стоит отметить, что если файл фрагментирован, но размещен компактной "кучкой" фрагментов - FAT32 всё же не испытывает больших трудностей, так как физический доступ к области FAT будет также компактен и буферизован. Поиск свободного дискового пространства Данная операция производится в том случае, если файл нужно создать с нуля или скопировать на диск. Поиск места под физические данные файла зависит от того, как хранится информация о занятых участках диска. На что влияет этот параметр: на скорость создания файлов, особенно больших. Сохранение или создание в реальном времени больших мультимедийных файлов (к примеру *.wav), копирование больших объемов информации и т.д. Этот параметр показывает, насколько быстро система сможет найти свободное пространство для записи на диск новых данных, и какие операции ей предстоит для этого выполнить. Для определения того, свободен данный кластер или нет, системы на основе FAT должны просмотреть одну запись FAT, соответствующую этому кластеру. Размер одной записи FAT16 составляет 16 бит, а одной записи FAT32 - 32 бита, отсюда и их названия. Для поиска свободного места на диске может потребоваться просмотреть почти весь FAT, а это - 128 КБ (максимум) для FAT16 и до нескольких мегабайт (!) - для FAT32. Для того чтобы не превращать поиск свободного места в катастрофу (для FAT32), операционной системе приходится идти на различные ухищрения. NTFS имеет битовую карту свободного места, одному кластеру соответствует 1 бит. Для поиска свободного места на диске приходится оценивать объемы в десятки раз меньшие, чем в системах FAT и FAT32. Вывод: NTFS имеет наиболее эффективную систему нахождения свободного места. Стоит отметить, что действовать "в лоб" на FAT16 или FAT32 очень медленно, поэтому для нахождения свободного места в этих системах применяются различные методы оптимизации, в результате чего и там достигается приемлемая скорость. Одно можно сказать наверняка - поиск свободного места при работе в DOS на FAT32 - катастрофический по скорости процесс, поскольку никакая оптимизация невозможна без поддержки серьезной операционной системы. Работа с каталогами и файлами Каждая файловая система выполняет элементарные операции с файлами - доступ, удаление, создание, перемещение и т.д. Скорость работы этих операций зависит от принципов организации хранения данных, от отдельных файлов и от устройства структур каталогов. На что влияет этот параметр: на скорость осуществления любых операций с файлом, в том числе - на скорость любой операции доступа к файлу, особенно - в каталогах с большим числом файлов (тысячи). FAT16 и FAT32 имеют очень компактные каталоги, размер каждой записи которых предельно мал. Более того, из-за сложившейся исторически системы хранения длинных имен файлов (более 11 символов), в каталогах систем FAT используется не очень эффективная и на первый взгляд неудачная, но зато очень экономная структура хранения этих самих длинных имен файлов. Работа с каталогами FAT производится достаточно быстро, так как в подавляющем числе случаев каталог (файл данных каталога) не фрагментирован и находится на диске в одном месте. Единственная проблема, которая может существенно понизить скорость работы каталогов FAT - большое количество файлов в одном каталоге (порядка тысячи или более). Система хранения данных - линейный массив - не позволяет организовать эффективный поиск файлов в таком каталоге, и для нахождения данного файла приходится перебирать большой объем данных (в среднем - половину файла каталога, подробнее о принципах поиска смотрите на стр. 24). NTFS использует более эффективный способ адресации - бинарное дерево, принцип работы которого был описан выше. Эта организация позволяет эффективно работать с каталогами любого размера - каталогам NTFS не страшно увеличение количества файлов в одном каталоге и до десятков тысяч. Стоит заметить, однако, что сам каталог NTFS представляет собой менее компактную структуру, нежели каталог FAT - это связано с большим (в несколько раз) размером одной записи каталога. Данное обстоятельство приводит к тому, что каталоги на томе NTFS в большем числе случаев сильно фрагментированы. Размер типичного каталога на FAT-е укладывается в один кластер, тогда как сотня файлов (и даже меньше) в каталоге на NTFS уже приводит к размеру файла каталога, превышающему типичный размер одного кластера. Это, в свою очередь, почти что гарантирует фрагментацию файла каталога и, к сожалению, довольно часто сводит на нет все преимущества более эффективной организации самих данных.
Вывод: структура каталогов на NTFS теоретически эффективнее, но при размере каталога в несколько сотен файлов, эта эффективность практически не имеет значения. Однако фрагментация каталогов NTFS уверенно наступает уже и при таком размере каталога. Для малых и средних каталогов NTFS, как это не печально, имеет на практике меньшее быстродействие.
Преимущества каталогов NTFS становятся реальными и неоспоримыми только в том случае, если в одном каталоге присутствуют тысячи файлов - в этом случае быстродействие компенсирует фрагментированность самого каталога и трудности с физическим обращением к данным (в первый раз - далее каталог кэшируется). Напряженная работа с каталогами, содержащими порядка тысячи и более файлов, проходит на NTFS буквально в несколько раз быстрее, а иногда выигрыш в скорости по сравнению с FAT и FAT32 достигает десятков раз. 2. Практика К сожалению, как это часто бывает во всевозможных компьютерных вопросах, практика не очень хорошо согласуется с теорией. NTFS имеющая, казалось бы, очевидные преимущества в структуре, показывает не настолько уж фантастические результаты, как можно было бы ожидать. Какие еще соображения влияют на быстродействие файловой системы? Каждый из рассматриваемых далее вопросов вносит свой вклад в итоговое быстродействие. Помните, однако, что реальное быстродействие - результат действия сразу всех факторов, поэтому и в этой части статьи не стоит делать поспешных выводов. Объем оперативной памяти (кэширование) Очень многие данные современных файловых систем кэшируются или буферизируются в памяти компьютера, что позволяет избежать лишних операций физического чтения данных с диска. Для нормальной (высокопроизводительной) работы системы в КЭШе приходится хранить следующие типы информации: Данные о физическом местоположении всех открытых файлов. Это, прежде всего, позволит обращаться к системным файлам и библиотекам, доступ к которым идет буквально постоянно, без чтения служебной (не относящейся к самим файлам) информации с диска. Это же относится к тем файлам, которые исполняются в данный момент - т.е. к выполняемым модулям (*.exe и *.dll) активных процессов в системе. В эту категорию попадают также файлы системы, с которыми производится работа (прежде всего реестр, виртуальная память, различные *.ini файлы, а также файлы документов и приложений). Наиболее часто используемые каталоги. К таковым можно отнести рабочий стол, меню "Пуск", системные каталоги, каталоги Интернет КЭШа, и т.п. Данные о свободном дисковом пространстве - т.е. та информация, которая позволит найти место для сохранения на диск новых данных. В случае если этот базовый объем информации не будет доступен прямо в оперативной памяти, системе придется совершать множество ненужных операций еще до того, как она начнет работу с реальными данными. Что входит в эти объемы в разных файловых системах? Или вопрос в более практической плоскости, - каким объемом свободной оперативной памяти надо располагать, чтобы эффективно работать с той или иной файловой системой? FAT16 имеет очень мало данных, отвечающих за организацию файловой системы. Из служебных областей можно выделить только саму область FAT, которая не может превышать 128 КБ (!) - эта область отвечает и за поиск фрагментов файлов, и за поиск свободного места на томе. Каталоги системы FAT также очень компактны. Общий объем памяти, необходимый для предельно эффективной работы с FAT-ом, может колебаться от сотни килобайт и до мегабайта-другого - при условии огромного числа и размера каталогов, с которыми ведется работа. FAT32 отличается от FAT16 лишь тем, что сама область FAT может иметь более внушительные размеры. На томах порядка 5 - 10 ГБ область FAT может занимать объем в несколько мегабайт, и это уже очень внушительный объем, надежно кэшировать который не представляется возможным. Тем не менее, область FAT, а вернее те фрагменты, которые отвечают за местоположение рабочих файлов, в подавляющем большинстве систем находятся в памяти машины - на это расходуется порядка нескольких мегабайт оперативной памяти. NTFS, к сожалению, имеет большие требования к памяти, необходимой для работы системы. Прежде всего, кэширование сильно затрудняет большие размеры каталогов. Размер одних только каталогов, с которыми активно ведет работу система, может запросто доходить до нескольких мегабайт и даже десятков мегабайт! Добавьте к этому необходимость кэшировать карту свободного места тома (сотни килобайт) и записи MFT для файлов, с которыми осуществляется работа (в типичной системе - по 1 КБ на каждый файл). К счастью, NTFS имеет удачную систему хранения данных, которая не приводит к увеличению каких-либо фиксированных областей при увеличении объема диска. Количество данных, с которым оперирует система на основе NTFS, практически не зависит от объема тома, и основной вклад в объемы данных, которые необходимо кэшировать, вносят каталоги. Тем не менее, уже этого вполне достаточно для того, чтобы только минимальный объем данных, необходимых для кэширования базовых областей NTFS, доходил до 5 - 8 МБ. К сожалению, можно с уверенностью сказать: NTFS теряет огромное количество своего теоретического быстродействия из-за недостаточного кэширования. На системах, имеющих менее 64 МБ оперативной памяти, NTFS просто не может оказаться быстрее FAT16 или FAT32. Единственное исключение из этого правила - диски FAT32, имеющие объем десятки гигабайт (я бы лично серьезно опасался дисков FAT32 объемом свыше, скажем, 30 ГБ). В остальных же случаях - системы с менее чем 64-я мегабайтами оперативной памяти просто обязаны работать с FAT32 быстрее. Типичный в настоящее время объем памяти в 64 МБ, к сожалению, также не дает возможности организовать эффективную работу с NTFS. На малых и средних дисках (до 10 ГБ) в типичных системах FAT32 будет работать, пожалуй, немного быстрее. Единственное, что можно сказать по поводу быстродействия систем с таким объемом оперативной памяти - системы, работающие с FAT32, будут гораздо сильнее страдать от фрагментации, чем системы на NTFS. Но если хотя бы изредка дефрагментировать диски, то FAT32, с точки зрения быстродействия, является предпочтительным вариантом. Многие люди, тем не менее, выбирают в таких системах NTFS - просто из-за того, что это даст некоторые довольно важные преимущества, тогда как типичная потеря быстродействия не очень велика. Системы с более чем 64-я МБ, а особенно - со 128-ю МБ и более оперативной памяти, смогут уверенно кэшировать абсолютно всё, что необходимо для работы систем, и вот как раз на таких то компьютерах NTFS, скорее всего, покажет более высокое быстродействие из-за более продуманной организации данных. Быстродействие дискового накопителя Влияют ли физические параметры жесткого диска на быстродействие файловой системы? Да, хоть и не сильно, но влияют. Можно выделить следующие параметры физической дисковой системы, которые по-разному влияют на различные типы файловых систем:
RST - (Random Seek Time - время случайного доступа). К сожалению, для доступа к системным областям на типичном диске более сложной файловой системы NTFS, винчестеру приходится совершать, в среднем, больше движений головками диска, чем в более простых системах FAT16 и FAT32. Большая фрагментация каталогов, возможность фрагментации системных областей - всё это делает диски NTFS гораздо более чувствительными к скорости считывания случайных (произвольных) областей диска. По этой причине использовать NTFS на медленных (старых) дисках не рекомендуется, так как высокое (худшее) время поиска дорожки дает еще один плюс в пользу систем FAT. Наличие Bus Mastering. Bus Mastering - специальный режим работы драйвера и контроллера, при использовании которого обмен с диском производится без участия процессора. Стоит отметить, что система запаздывающего кэширования NTFS сможет действовать гораздо более эффективно при наличии Bus Mastering, т.к. NTFS производит отложенную запись большего числа данных. Системы без Bus Mastering в настоящее время встречаются достаточно редко (обычно это накопители или контроллеры, работающие в режиме PIO3 или PIO4), и если вы работаете с таким диском - то, скорее всего, NTFS потеряет еще пару очков быстродействия, особенно при операциях модификации каталогов (например, активная работа в Интернете - работа с КЭШем Интернет). Кэширование, как чтения, так и записи на уровне жестких дисков (объем буфера HDD (Hard Disk Drive – жесткий диск (винчестер)) - от 128 КБ до 1-2 МБ в современных дорогих дисках) - фактор, который будет более полезен системам на основе FAT. NTFS же из соображений надежности хранения информации осуществляет модификацию системных областей с флагом "не кэшировать запись", поэтому быстродействие системы NTFS слабо зависит от возможности кэширования самого HDD. Системы FAT, напротив, получат некоторый плюс от кэширования записи на физическом уровне. Так что хочу отметить, что, вообще говоря, всерьез принимать в расчет размер буфера HDD при оценке быстродействия тех или иных файловых систем не стоит.
Подводя краткий итог влияния быстродействия диска и контроллера на быстродействия системы в целом, можно сказать так: NTFS страдает от медленных дисков гораздо сильнее, чем FAT. Размер кластера Хотелось бы сказать пару слов о размере кластера - тот параметр, который в файловых системах FAT32 и NTFS можно задавать при форматировании практически произвольно. Прежде всего, надо сказать, что больший размер кластера - это практически всегда большее быстродействие. Однако, размер кластера на томе NTFS, имеет меньшее влияние на быстродействие, чем размер кластера для FAT32. Типичный размер кластера для NTFS - 4 КБ. Стоит отметить, что при большем размере кластера отключается встроенная в файловую систему возможность сжатия индивидуальных файлов, а также перестает работать стандартная API дефрагментация - т.е. подавляющее число дефрагментаторов, в том числе встроенный в Windows 2000/XP, будут неспособны дефрагментировать этот диск. SpeedDisk, впрочем, сможет - он работает без использования API. Оптимальным с точки зрения быстродействия, по крайней мере, для средних и больших файлов, считается (самой Microsoft) размер 16 КБ. Увеличивать размер далее неразумно из-за слишком больших расходов на неэффективность хранения данных и из-за мизерного дальнейшего увеличения быстродействия. Если вы хотите повысить быстродействие NTFS ценой потери возможности сжатия - задумайтесь о форматировании диска с размером кластера, большим, чем 4 КБ. Но имейте в виду, что это даст довольно скромный прирост быстродействия, который часто не стоит даже уменьшения эффективности размещения файлов на диске. Быстродействие системы FAT32, напротив, можно довольно существенно повысить, увеличив размер кластера. Если в NTFS размер кластера почти не влияет на размер и характер данных системных областей, то в системе FAT увеличивая кластер в два раза, мы сокращаем область FAT в те же два раза. Вспомните, что в типичной системе FAT32 эта очень важная для быстродействия область занимает несколько мегабайт. Сокращение области FAT в несколько раз даст заметное увеличение быстродействия, так как объем системных данных файловой системы сильно сократиться - уменьшается и время, затрачиваемое на чтение данных о расположении файлов, и объем оперативной памяти, необходимый для буферизации этой информации. Типичный объем кластера для систем FAT32 составляет тоже 4 КБ, и увеличение его до 8 или даже до 16 КБ - особенно для больших (десяток и более гигабайт) дисков - достаточно разумный шаг. Другие соображения NTFS является достаточно сложной системой, поэтому, в отличие от FAT16 и FAT32, имеются и другие факторы, которые могут привести к существенному замедлению работы NTFS: Диск NTFS был получен преобразованием раздела FAT16 или FAT32 (команда convert). Данная процедура в большинстве случаев представляет собой тяжелый случай для быстродействия, так как структура служебных областей NTFS, чаще всего, получится очень фрагментированной. Если есть возможность - избегайте преобразования других систем в NTFS, так как это приведет к созданию очень неудачного диска, которому не поможет даже типичный (неспециализированный) дефрагментатор, типа Diskeeper-а или встроенного в Windows 2000/XP. Активная работа с диском, заполненным более чем на 80% - 90%, представляет собой катастрофический для быстродействия NTFS случай, так как фрагментация файлов и, самое главное, служебных областей, будет расти фантастически быстро. Если ваш диск используется в таком режиме - FAT32 будет более удачным выбором при любых других условиях. 3. Выводы В данной заключительной части "одной строчкой" собраны ключевые особенности быстродействия этих трех файловых систем. FAT - плюсы: Для эффективной работы требуется немного оперативной памяти. Быстрая работа с малыми и средними по количеству файлов каталогами. Диск совершает в среднем меньшее количество движений головок (по сравнению с NTFS). Эффективная работа на медленных дисках. FAT - минусы: Катастрофическая потеря быстродействия с увеличением фрагментации, особенно для больших дисков (только FAT32). Сложности с произвольным доступом к большим (скажем, 10% и более от размера диска) файлам. Очень медленная работа с каталогами, содержащими большое количество файлов. NTFS - плюсы: Фрагментация файлов не имеет практически никаких последствий для самой файловой системы - работа фрагментированной системы ухудшается только с точки зрения доступа к самим данным файлов. Сложность структуры каталогов и число файлов в одном каталоге также не создает особых препятствий быстродействию. Быстрый доступ к произвольному фрагменту файла (например, редактирование больших *.wav файлов). Очень быстрый доступ к маленьким файлам (несколько сотен байт) - весь файл находится в том же месте, где и системные данные (запись MFT).
NTFS - минусы: Существенные требования к оперативной памяти системы (64 МБ - абсолютный минимум, лучше - больше). Медленные диски и контроллеры без Bus Mastering сильно снижают быстродействие NTFS. Работа с каталогами средних размеров затруднена тем, что они почти всегда фрагментированы. Диск, долго работающий в заполненном на 80% - 90% состоянии, будет показывать крайне низкое быстродействие.
Хотелось бы еще раз подчеркнуть, что на практике основной фактор, от которого зависит быстродействие файловой системы - это, как ни странно, объем оперативной памяти машины. Системы с памятью 64-96 МБ - некий рубеж, на котором быстродействие NTFS и FAT32 примерно эквивалентно. Обратите внимание также на сложность организации данных на вашей машине. Если вы не используете ничего, кроме простейших приложений и самой операционной системы - может случиться так, что FAT32 сможет показать более высокое быстродействие и на машинах с большим количеством памяти. NTFS - система, которая закладывалась на будущее, и это будущее для большинства реальных применений сегодняшнего дня, ещё, к сожалению, видимо не наступило. На данный момент NTFS обеспечивает стабильное и равнодушное к целому ряду факторов, но, пожалуй, всё же невысокое - на типичной "игровой" домашней системе - быстродействие. Основное преимущество NTFS с точки зрения быстродействия заключается в том, что этой системе безразличны такие параметры, как сложность каталогов (число файлов в одном каталоге), размер диска, фрагментация и т.д. В системах FAT же, напротив, каждый из этих факторов приведет к существенному снижению скорости работы. Только в сложных высокопроизводительных системах - например, на графических станциях или просто на серьезных офисных компьютерах с тысячами документов, или, тем более, на файл-серверах - преимущества структуры NTFS смогут дать реальный выигрыш быстродействия, который порой заметен невооруженным глазом. Пользователям, не имеющим диски крупного размера, забитые информацией, и не пользующимся сложным программным обеспечением, не стоит ждать от NTFS чудес скорости - с точки зрения быстродействия на простых домашних системах гораздо лучше покажет себя FAT32. Список литературы 1. Г.С.Иванова, Т.Н.Ничушкина, Е.К.Пугачев «Объектно-ориентированное программирование». Москва, Издательство МГТУ имени Н.Э.Баумана 2001. 2. В.Озеров «Информация | Файловые системы и все что к ним относится». 2001.