|
Главная | Форум |
|
Игры | Софт | Музыка | Видео приколы | Фото приколы | Новости | CD диски | Хостинг | Информер |
Навигация
| Структура NTFS 1. Физическая
структура NTFS Начнем с общих фактов. Раздел NTFS, теоретически, может быть почти какого угодно размера. Предел, конечно, есть, но я даже не буду указывать его, так как его с запасом хватит на последующие сто лет развития вычислительной техники - при любых темпах роста. Как обстоит с этим дело на практике? Почти так же. Максимальный размер раздела NTFS в данный момент ограничен лишь размерами жестких дисков. Структура раздела - общий взгляд Как и любая другая система, NTFS делит все полезное место на кластеры - блоки данных, используемые единовременно. NTFS поддерживает почти любые размеры кластеров - от 512 байт до 64 Кбайт, неким стандартом же считается кластер размером 4 Кбайт. Никаких аномалий кластерной структуры NTFS не имеет, поэтому на эту, в общем-то, довольно банальную тему, сказать особо нечего. Диск NTFS условно делится на две части. Первые 12% диска отводятся под так называемую MFT зону - пространство, в которое растет метафайл MFT (об этом ниже). Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой - это делается для того, чтобы самый главный, служебный файл (MFT) не фрагментировался при своем росте. Остальные 88% диска представляют собой обычное пространство для хранения файлов. Свободное место диска, однако, включает в себя всё физически свободное место - незаполненные куски 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. В следующей таблице приведены используемые в данный момент метафайлы и их назначение.
Итак, у системы есть файлы - и ничего кроме файлов. Что включает в себя это понятие на NTFS?
Довольно интересно обстоит дело и с данными файла. Каждый файл на NTFS, в общем-то, имеет несколько абстрактное строение - у него нет как таковых данных, а есть потоки (streams). Один из потоков и носит привычный нам смысл - данные файла. Но большинство атрибутов файла - тоже потоки! Таким образом, получается, что базовая сущность у файла только одна - номер в MFT, а всё остальное опционально. Данная абстракция может использоваться для создания довольно удобных вещей - например, файлу можно "прилепить" еще один поток, записав в него любые данные - например, информацию об авторе и содержании файла, как это сделано в Windows XP (самая правая закладка в свойствах файла, просматриваемых из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами: наблюдаемый размер файла - это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длинны, при стирании которого освободится 1 Гбайт свободного места - просто потому, что какая-нибудь хитрая программа или технология прилепила в нему дополнительный поток (альтернативные данные) гигабайтового размера. Но на самом деле в текущий момент потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны. Просто имейте в виду, что файл на NTFS - это более глубокое и глобальное понятие, чем можно себе вообразить просто просматривая каталоги диска. Ну и напоследок: имя файла может содержать любые символы, включая полый набор национальных алфавитов, так как данные представлены в Unicode - 16-битном представлении, которое дает 65535 разных символов. Максимальная длина имени файла - 255 символов. Каталог на NTFS представляет собой специфический файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение данных на диске. Файл каталога поделен на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент MFT, который уже предоставляет полную информацию об элементе каталога. Внутренняя структура каталога представляет собой бинарное дерево. Вот что это означает: для поиска файла с данным именем в линейном каталоге, таком, например, как у FAT-а, операционной системе приходится просматривать все элементы каталога, пока она не найдет нужный. Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся более быстрым способом - с помощью получения двухзначных ответов на вопросы о положении файла. Вопрос, на который бинарное дерево способно дать ответ, таков: в какой группе, относительно данного элемента, находится искомое имя - выше или ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает зону поиска в среднем в два раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на вопрос осуществляется очевидным способом - сравнением начальных букв. Область поиска, суженная в два раза, начинает исследоваться аналогичным образом, начиная опять же со среднего элемента. Вывод - для поиска одного файла среди 1000,
например, FAT придется осуществить в среднем 500 сравнений (наиболее
вероятно, что файл будет найден на середине поиска), а системе на
основе дерева - всего около 10-ти (2^10 = 1024). Экономия времени
поиска налицо. Не стоит, однако думать, что в традиционных системах
(FAT) всё так запущено: во-первых, поддержание списка файлов в виде
бинарного дерева довольно трудоемко, а во-вторых - даже FAT в
исполнении современной системы
использует сходную оптимизацию поиска. Это просто еще один факт в
вашу копилку знаний. Хочется также развеять распространенное
заблуждение (которое я сам разделял совсем еще недавно) о том, что
добавлять файл в каталог в виде дерева труднее, чем в линейный
каталог: это достаточно сравнимые по времени операции - дело в том,
что для того, чтобы добавить файл в каталог, нужно сначала убедится,
что файла с таким именем там еще нет :) - и вот тут-то в линейной
системе у нас будут трудности с поиском файла, описанные выше,
которые с лихвой компенсируют саму простоту добавления файла в
каталог. Какую информацию можно получить, просто прочитав
файл каталога? Ровно то, что выдает команда dir. Для выполнения
простейшей навигации по диску не нужно лазить в MFT за каждым
файлом, надо лишь читать самую общую информацию о файлах из файлов
каталогов. Главный каталог диска - корневой - ничем не отличается об
обычных каталогов, кроме специальной ссылки на него из начала
метафайла MFT. NTFS - отказоустойчивая система, которая вполне
может привести себя в корректное состояние при практически любых
реальных сбоях. Любая современная файловая система основана на таком
понятии, как транзакция - действие, совершаемое
целиком и корректно или не совершаемое вообще. У NTFS просто не
бывает промежуточных (ошибочных или некорректных) состояний - квант
изменения данных не может быть поделен на до и после сбоя, принося
разрушения и путаницу - он либо совершен, либо отменен. Пример 1: осуществляется
запись данных на диск. Вдруг выясняется, что в то место, куда мы
только что решили записать очередную порцию данных, писать не
удалось - физическое повреждение поверхности. Поведение NTFS в этом
случае довольно логично: транзакция записи откатывается целиком -
система осознает, что запись не произведена. Место помечается как
сбойное, а данные записываются в другое место - начинается новая
транзакция. Пример 2: более сложный
случай - идет запись данных на диск. Вдруг, бах - отключается
питание и система перезагружается. На какой фазе остановилась
запись, где есть данные, а где чушь? На помощь приходит другой
механизм системы - журнал транзакций. Дело в том, что система,
осознав свое желание писать на диск, пометила в метафайле $LogFile
это свое состояние. При перезагрузке это файл изучается на предмет
наличия незавершенных транзакций, которые были прерваны аварией и
результат которых непредсказуем - все эти транзакции отменяются:
место, в которое осуществлялась запись, помечается снова как
свободное, индексы и элементы MFT приводятся в с состояние, в
котором они были до сбоя, и система в целом остается стабильна. Ну а
если ошибка произошла при записи в журнал? Тоже ничего страшного:
транзакция либо еще и не начиналась (идет только попытка записать
намерения её произвести), либо уже закончилась - то есть идет
попытка записать, что транзакция на самом деле уже выполнена. В
последнем случае при следующей загрузке система сама вполне
разберется, что на самом деле всё и так записано корректно, и не
обратит внимания на "незаконченную" транзакцию. И все-таки помните, что журналирование - не
абсолютная панацея, а лишь средство существенно сократить число
ошибок и сбоев системы. Вряд ли рядовой пользователь NTFS хоть
когда-нибудь заметит ошибку системы или вынужден будет запускать
chkdsk - опыт показывает, что NTFS восстанавливается в полностью
корректное состояние даже при сбоях в очень загруженные дисковой
активностью моменты. Вы можете даже оптимизировать диск и в самый
разгар этого процесса нажать reset - вероятность потерь данных даже
в этом случае будет очень низка. Важно понимать, однако, что система
восстановления NTFS гарантирует корректность файловой
системы, а не ваших данных. Если вы производили запись на
диск и получили аварию - ваши данные могут и не записаться. Чудес не
бывает. Файлы NTFS имеют один довольно полезный атрибут -
"сжатый". Дело в том, что NTFS имеет встроенную поддержку сжатия
дисков - то, для чего раньше приходилось использовать Stacker или
DoubleSpace. Любой файл или каталог в индивидуальном порядке может
хранится на диске в сжатом виде - этот процесс совершенно прозрачен
для приложений. Сжатие файлов имеет очень высокую скорость и только
одно большое отрицательное свойство - огромная виртуальная
фрагментация сжатых файлов, которая, правда, никому особо не мешает.
Сжатие осуществляется блоками по 16 кластеров и использует так
называемые "виртуальные кластеры" - опять же предельно гибкое
решение, позволяющее добиться интересных эффектов - например,
половина файла может быть сжата, а половина - нет. Это достигается
благодаря тому, что хранение информации о компрессированности
определенных фрагментов очень похоже на обычную фрагментацию файлов:
например, типичная запись физической раскладки для реального,
несжатого, файла: кластеры файла с 1 по 43-й хранятся в кластерах
диска начиная с 400-го Физическая раскладка типичного сжатого файла: кластеры файла с 1 по 9-й хранятся в кластерах
диска начиная с 400-го
Видно, что сжатый файл имеет "виртуальные"
кластеры, реальной информации в которых нет. Как только система
видит такие виртуальные кластеры, она тут же понимает, что данные
предыдущего блока, кратного 16-ти, должны быть разжаты, а
получившиеся данные как раз заполнят виртуальные кластеры - вот, по
сути, и весь алгоритм. NTFS содержит множество средств разграничения прав
объектов - есть мнение, что это самая совершенная файловая система
из всех ныне существующих. В теории это, без сомнения, так, но в
текущих реализациях, к сожалению, система прав достаточно далека от
идеала и представляет собой хоть и жесткий, но не всегда логичный
набор характеристик. Права, назначаемые любому объекту и однозначно
соблюдаемые системой, эволюционируют - крупные изменения и
дополнения прав осуществлялись уже несколько раз и к Windows XP
все-таки они пришли к достаточно разумному набору. Права файловой системы NTFS неразрывно связаны с
самой системой - то есть они, вообще говоря, необязательны к
соблюдению другой системой, если ей дать физический доступ к диску.
Для предотвращения физического доступа в Windows XP всё же
ввели стандартную возможность - об этом см. ниже. Система прав в
своем текущем состоянии достаточно сложна, и я сомневаюсь, что смогу
сказать широкому читателю что-нибудь интересное и полезное ему в
обычной жизни. Если вас интересует эта тема - вы найдете множество
книг по сетевой архитектуре NT, в которых это описано более чем
подробно. На этом описание строение файловой системы можно
закончить, осталось описать лишь некоторое количество просто
практичных или оригинальных вещей. Эта штука была в NTFS с незапамятных времен, но
использовалась очень редко - и тем не менее: Hard Link - это когда
один и тот же файл имеет два имени (несколько указателей
файла-каталога или разных каталогов указывают на одну и ту же MFT
запись). Допустим, один и тот же файл имеет имена 1.txt и 2.txt:
если пользователь сотрет файл 1, останется файл 2. Если сотрет 2 -
останется файл 1, то есть оба имени, с момента создания, совершенно
равноправны. Файл физически стирается лишь тогда, когда будет
удалено его последнее имя. Гораздо более практичная возможность, позволяющая
делать виртуальные каталоги - ровно так же, как и виртуальные диски
командой subst в DOSе. Применения достаточно разнообразны:
во-первых, упрощение системы каталогов. Если вам не нравится каталог
Documents and settings\Administrator\Documents, вы можете
прилинковать его в корневой каталог - система будет по прежнему
общаться с каталогом с дремучим путем, а вы - с гораздо более
коротким именем, полностью ему эквивалентным. Для создания таких
связей можно воспользоваться программой junction (junction.zip
(15 Kb), 36 кб), которую написал известный специалист Mark
Russinovich (http://www.sysinternals.com/). Для удаления связи можно воспользоваться стандартной
командой rd. ВНИМАНИЕ: Попытка удаления связи с помощью проводника
или других файловых менеджеров, не понимающих виртуальную природу
каталога (например, FAR), приведет к удалению данных, на которые
ссылается ссылка! Будьте осторожны. Полезная возможность для людей, которые беспокоятся
за свои секреты - каждый файл или каталог может также быть
зашифрован, что не даст возможность прочесть его другой
ОС. В сочетании со стандартным и практически непрошибаемым паролем
на загрузку самой системы, эта возможность обеспечивает достаточную
для большинства применений безопасность избранных вами важных
данных. |
| ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||
Copyright © 2004 www.art-soft.ru all Rights Reserved. |