Главная
О нас
Наши собаки
- Репортаж
- Фотоальбом
- Видео
Информация
- Новости
- Статьи
- Ветеринария
- Разное
Юмор
Форум
Контакты

Это интересно

ОКД
ЗКС
ИПО
КНПВ
Мондиоринг
Большой ринг
Французский ринг
Аджилити
Фризби

Опрос

Какой уровень дрессировки необходим Вашей собаке?

	Элементарное послушание в быту
	Чёткое выполнение команд
	Спорт и соревнования

Полезные ссылки

РКФ

Все о дрессировке собак

Стрижка собак в Коломне

Поиск по сайту

Структура тома с файловой системой NTFS. Журнал тома ntfs

Структура тома с файловой системой ntfs

Рассмотрим теперь структуру файловой системы NTFS. Наиболее полно она описана в книге [23]. Мы же здесь коснемся только основных моментов.

Одним из основных понятий, используемых при работе с NTFS, является понятие тома (volume)1. Возможно также создание отказоустойчивого тома, занимающего несколько разделов, то есть использование RAID-технологии. Как и многие другие системы, NTFS делит всё полезное дисковое пространство тома на кластеры – блоки данных, адресуемые как единицы данных. NTFS поддерживает размеры кластеров от 512 байт до 64 Кбайт; стандартом же считается кластер размером 2 или 4 Кбайт.

Всё дисковое пространство в NTFS делится на две неравные части (рис.4.12). Первые 12 % диска отводятся под так называемую MFT-зону – пространство, которое может занимать, увеличиваясь в размере, главный служебный метафайл MFT2.Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой – это делается для того, чтобы самый главный, служебный файл (MFT) по возможности не фрагментировался при своем росте. Остальные 88 % тома представляют собой обычное пространство для хранения файлов.

Рис.4.12. Структура тома NTFS

MFT(masterfiletable, общая таблица файлов) представляет собой централизованный каталог всех остальных файлов диска, в том числе и себя самого. MFT поделен на записи фиксированного размера в 1 Кбайт1, и каждая запись соответствует какому-либо файлу (в общем смысле этого слова). Первые 16 файлов носят служебный характер и недоступны операционной системе – они называютсяметафайлами,причем самый первый метафайл – сам MFT. Эти первые 16 элементовMFT– единственная часть диска, имеющая строго фиксированное положение. Копия этих же 16 записей хранится в середине тома для надёжности, поскольку они очень важны. Остальные части MFT-файла могут располагаться, как и любой другой файл, в произвольных местах диска – восстановить его положение можно с помощью его самого, «зацепившись» за самую основу – за первый элемент MFT.

Таблица 4.7.Метафайлы NTFS

Имя метафайла	Назначение метафайла
$MFT	Сам Master File Table
$MFTmirr	Копия первых 16 записей MFT, размещенная посередине тома
$LogFile	Файл поддержки операций журналирования
$Volume	Служебная информация – метка тома, версия файловой системы и т. д.
$AttrDef	Список стандартных атрибутов файлов на томе
$.	Корневой каталог
$ Bitmap	Карта свободного места тома
$Boot	Загрузочный сектор (если раздел загрузочный)
$Quota	Файл, в котором записаны права пользователей на использование дискового пространства (этот файл начал работать лишь в Windows 2000 с системой NTFS 5.0)
$Upcase	Файл – таблица соответствия заглавных и прописных букв в именах файлов. В NTFS имена файлов записываются в Unicode (что составляет 65 тысяч различных символов) и искать большие и малые эквиваленты в данном случае – нетривиальная задача

Упомянутые первые 16 файлов NTFS (метафайлы) носят служебный характер; каждый из них отвечает за какой-либо аспект работы системы. Метафайлы находятся в корневом каталоге NTFS-тома. Все они начинаются с символа имени «$», хотя получить какую-либо информацию о них стандартными средствами сложно.

В табл. 4.7 приведены основные известные метафайлы и их назначение. Таким образом, можно узнать, например, сколько операционная система тратит на каталогизацию тома, посмотрев размер файла $MFT.

Итак, все файлы тома упоминаются в MFT. В этой структуре хранится вся информация о файлах, за исключением собственно данных. Имя файла, размер, положение на диске отдельных фрагментов и т. д. – всё это хранится в соответствующей записи. Если для информации не хватает одной записи MFT, то используется несколько записей, причем не обязательно идущих подряд. Файлы могут иметь не очень большой размер. Тогда применяется довольно удачное решение: данные файла хранятся прямо в MFT, в оставшемся от основных данных месте в пределах одной записи MFT. Файлы, занимающие сотни байт, обычно не имеют своего «физического» воплощения в основной файловой области – все данные такого файла хранятся в одном месте, в MFT.

Файл в томе с NTFS идентифицируется так называемой файловой ссылкой (FileReference), которая представляется как 64-разрядное число. Файловая ссылка состоит из номера файла, который соответствует позиции его файловой записи в MFT, и номера последовательности. Последний увеличивается всякий раз, когда данная позиция в MFT используется повторно, что позволяет файловой системе NTFS выполнять внутренние проверки целостности.

Каждый файл в NTFS представлен с помощью потоков(streams), то есть у него нет как таковых «просто данных», а есть «потоки». Для правильного понимания потока достаточно указать, что один из потоков и носит привычный нам смысл – данные файла. Но большинство атрибутов файла – это тоже потоки. Таким образом, получается, что базовая сущность у файла только одна – номер в MFT, а всё остальное, включая и его потоки, – опционально. Данный подход может эффективно использоваться – например, файлу можно «прилепить» ещё один поток, записав в него любые данные. ВWindows2000 таким образом записана информация об авторе и содержании файла (одна из закладок в свойствах файла, просматриваемых, например, из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами работы с файлами: наблюдаемый размер файла – это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длины, при стирании которого освободится 1 Гбайт свободного места – просто потому, что какая-нибудь хитрая программа или технология «прилепила» к нему дополнительный поток (альтернативные данные) такого большого размера. Но на самом деле в настоящее время потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны1. Просто необходимо иметь в виду, что файл в NTFS –это более глубокое понятие, чем можно себе представить, просматривая каталоги диска.

Стандартные же атрибуты для файлов и каталогов в томе NTFS имеют фиксированные имена и коды типа, они перечислены в табл. 4.8.

Таблица 4.8.Атрибуты файлов в системе NTFS

Системный атрибут	Описание атрибута
Стандартная информация о файле	Традиционные атрибуты Read Only, Hidden, Archive, System, отметки времени, включая время создания или последней модификации, число каталогов, ссылающихся на файл
Список атрибутов	Список атрибутов, из которых состоит файл, и файловая ссылка на файловую запись и MFT, в которой расположен каждый из атрибутов. Последний используется, если файлу необходимо более одной записи в MFT
Имя файла	Имя файла в символах Unicode. Файл может иметь несколько атрибутов – имён файла, подобно тому как это имеет место в UNIX-Системах. Это случается, когда имеется связь POSIX с данным файлом или если у файла есть автоматически сгенерированное имя в формате 8.3
Дескриптор защиты	Структура данных защиты (ACL), предохраняющая файл от несанкционированного доступа. Атрибут «дескриптор защиты» определяет, кто владелец файла и кто имеет доступ к нему
Данные	Собственно данные файла, его содержимое. В NTFS у файла по умолчанию есть один безымянный атрибут данных, и он может иметь дополнительные именованные атрибуты данных. У каталога нет атрибута данных по умолчанию, но он может иметь необязательные именованные атрибуты данных
Корень индекса, размещение индекса, битовая карта (только для каталогов)	Атрибуты, используемые для индексов имён файлов в больших каталогах
Расширенные атрибуты HPFS	Атрибуты, используемые для реализации расширенных атрибутов HPFS для подсистемы OS/2 и OS/2–клиентов файл-серверов Windows NT

Атрибуты файла в записях MFTрасположены в порядке возрастания числовых значений кодов типа, причем некоторые типы атрибутов могут встречаться в записи более одного раза: например, если у файла есть несколько атрибутов данных или несколько имен. Обязательными для каждого файла в томеNTFSявляются атрибут стандартной информации, атрибут имени файла, атрибут дескриптора защиты и атрибут данных. Остальные атрибуты могут встречаться при необходимости.

Имя файла в NTFS, в отличие от файловых систем FATиHPFS, может содержать любые символы, включая полный набор национальных алфавитов, так как данное представлены вUnicode– 16-битном представлении, которое дает 65 535 разных символов. Максимальная длина имени файла в NTFS – 255 символов.

Большой вклад в эффективность файловой системы вносит организация каталога. Каталог в NTFS представляет собой специальный файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение данных на диске. Файл каталога поделён на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент MFT, который уже предоставляет полную информацию об элементе каталога. Главный каталог диска – корневой – ничем не отличается от обычных каталогов, кроме специальной ссылки на него из начала метафайла MFT.

Внутренняя структура каталога представляет собой бинарное дерево, подобно тому, как это организовано в HPFS. Кстати, при создании файловой системы NTFS разработчики решили использовать максимально возможное количество эффективных решений из HPFS. К сожалению, не было взято на вооружение разбиение всего дискового пространства на зоны, в каждой из которых хранилась бы информация об имеющихся свободных кластерах. В результате отказа от этого подхода и введения механизма транзакций скорость работы файловой системы NTFS существенно ниже скорости работы системы HPFS.

Итак, как нам теперь известно, бинарное дерево каталога располагает имена файлов таким образом, чтобы поиск файла осуществлялся с помощью получения двухзначных ответов на вопросы о положении файла. Бинарное дерево способно дать ответ на вопрос: в какой группе, относительно данного элемента, находится искомое имя – выше или ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает зону поиска в среднем в два раза. Если представить, что файлы отсортированы по алфавиту, то ответ на вопрос осуществляется очевидным способом – сравнением начальных букв. Область поиска, суженная в два раза, начинает исследоваться аналогичным образом, начиная опять же со среднего элемента.

Заметим, что добавлять файл в каталог в виде дерева не намного труднее, чем в линейный каталог системы FAT. Это сопоставимые по времени операции. Для того чтобы добавить новый файл в каталог, нужно сначала убедиться, что файла с таким именем там ещё нет. Поэтому в системеFATс линейной организацией записей каталога у нас появляются трудности не только с поиском файла. И это с лихвой компенсирует саму простоту добавления файла в каталог.

studfiles.net

Команда fsutil USN | Энциклопедия Windows

Команда fsutil USN используется для опроса и управления журналом изменений NTFS Change Journal на указанном томе. Многие не подозревают о существовании такого журнала, так как это достаточно новая (появившаяся только в Windows 2000 и более поздних версиях) возможность файловой системы.

В основном журнал изменений (Change Journal) оказывается полезным для программ резервного копирования, так как позволяет ускорить процесс инкрементного резервного копирования. В операционных системах Windows, которые существовали до появления Windows 2000, при выполнении инкрементного копирования сканировался весь том, что позволяло составить список файлов, изменившихся с момента последнего резервного копирования.

Этот список являлся результатом проверки состояния флага архивирования или сравнения отметки времени последнего резервного копирования файла. Вне зависимости от метода составления этого списка, проблемной стороной этого процесса являлась потребность в ресурсах и времени, которые не всегда есть в наличии, если компьютер поддерживает работу, например, веб-сервера IIS. Еще одной проблемой использования флага архивирования и сканирования отметки времени последнего архивирования является неизменность флага или отметки при переименовании файла или при изменении связанного с ним списка прав доступа. Это означает, что такие файлы не будут входить в инкрементную резервную копию.

Все эти проблемы были исправлены в момент появления журнала изменений NTFS. Использование Change Journal позволяет операционной системе поддерживать собственный индекс файлов и записывать изменения с помощью номеров последовательности обновления (Update Sequence Number — USN). Даже изменения в имени файла или в списке прав доступа записываются в журнал изменений. Приложения резервного копирования, которые по настоящему совместимы с Windows 2000 и более поздними версиями операционной системы Windows, могут использовать Change Journal.

Это означает, что при выполнении инкрементного резервного копирования сканирование всего тома не требуется. Вместо этого список копируемых файлов создается с помощью содержимого Change Journal, что экономит время и ресурсы. Кроме этого, возможность записывать в инкрементные резервные копии изменения в именах и списках прав доступа файлов делает приложения резервного копирования, способные использовать журнал изменений, более точными.

Кроме программ для резервного копирования Change Journal используется следующими службами Windows:

Служба репликации файлов (File Replication Services)
Служба индексирования (Indexing Service)
Служба удаленной установки (Remote Installation Service)
Служба удаленного хранения (Remote Storage Service)

В частности, команда fsutil USN позволяет выполнять следующие административные операции по отношению к тому с включенным Change Journal:

Создавать новый Change Journal
Вносить изменения в существующий Change Journal
Отображать список записей Change Journal между определенными значениями USN
Получать общую информацию о Change Jounal (вместимость, информацию о записях)
Отображать данные USN для определенного файла

Эти задачи выполняются с помощью такого синтаксиса команды fsutil USN:

fsutil USN createjournal <MaxSize> <AllocationDelta> <VolumePath> fsutil USN deletejournal <flags> <VolumePath> fsutil USN enumdata <FileRef> <LowUSN> <HighUSN> <VolumePath> fsutil USN queryjournal <VolumePath> fsutil USN readdata <FilePath>

Несложно заметить, что существует несколько вариантов этой команды. Параметры каждой версии команды рассматриваются в следующей таблице.

Параметры команды fsutil USN

Параметр	Использование
createjournal	Создает новый Change Journal на указанном томе. Если такой журнал уже существует, параметры Change Journal меняются на указанные в команде
Maxsize	Используется для указания максимального размера журнала (в байтах) для выделения дискового пространства для Change Journal
AllocationDelta	Используется для указания объема данных (в байтах), которые должны быть удалены в начале и добавлены в конец Change Journal. Другими словами, как только Change Journal достигнет максимального размера указанный этим параметром объем старых данных будет стерт для освобождения места новым данным
VolumePath	Используется для указания буквы диска или пути монтирования интересующего тома
deletejournal	Используется для отключения активного Change Journal
flags	Существуют два флага команды fsutil USN deletejournal: /d — отключает активный Change Journal с возвратом управления вводом/выводом системе до завершения операции отключения. /n — отключает активный Change Journal с возвратом управления вводом/выводом системе после завершения операции отключения.
enumdata	Перечисляет данные Change Journal между двумя указанными точками
FileRef	Указывает ординальную позицию файла, в которой начинается перечисление
LowUSN	Указывает нижнюю границу записей USN в Change Journal, которые возвращаются в выводе команды
HighUSN	Указывает верхнюю границу записей USN в Change Journal, которые возвращаются в выводе команды. Файлы, USN которых равны или попадают в интервал от LowUSN до HighUSN, возвращаются командой
queryjournal	Используется для отображения конфигурационной информации Change Journal. Эта информация содержит первый USN, максимальный размер журнала и разность выделения
readdata	Используется для отображения данных USN для определенного файла
Filepath	Используется для указания полного пути к файлу, который должен быть проверен с помощью команды fsutil USN readdata

Хотя эта команда и сложна, существуют ситуации когда она необходима для решения возникшей проблемы или диагностики. Предположим, что существуют подозрения в неполном инкрементном резервном копировании изменений с диска D. Есть вероятность, что выделенный размер Change Journal является недостаточным для данного тома.

В этом случае необходимо или чаще выполнять инкрементное резервное копирование или увеличить размер Change Journal. Предположим, что для обеспечения корректности резервного копирования необходимо увеличить размер Change Journal до 500МВ. Кроме этого, старые данные должны замещаться новыми порциями по 5МВ. Перед запуском этой команды необходимо преобразовать оба значения из мегабайт в байты. Получается 524288000 и 5242880, соответственно (1МВ = 1048576 байт). Эти значения можно использовать в следующей команде:

fsutil USN createjournal 524288000 5242880 D:

Использование журнала изменений NTFS Change Journal позволяет повысить эффективность работы с файловой системой NTFS.

windata.ru

Специальные файлы NTFS

Первые шестнадцать элементов главной таблицы файлов (MFT — Master File Table) зарезервированы для специальных файлов. В NTFS 3.0 используются только первые двенадцать элементов. Это скрытые файлы, имена которых расположены в корне раздела. Файлов не видно, но, тем не менее, они существуют. Проверить это можно, попытавшись создать файл с одним из зарезервированных имён в корне раздела. На диске с NTFS, например, не получится создать файл C:\$Volume.

$MFT (элемент 0) Главная таблица файлов. Атрибут данных содержит элементы MFT, а также неиспользуемые растровые атрибуты.
$MFTMirr (элемент 1) Зеркало (резервная копия) первых четырёх элементов MFT.
$LogFile (элемент 2) Файл журнала тома, в который записываются все изменения структуры тома.
$Volume (элемент 3) Атрибут данных $Volume представляет весь том. Обращение Win32 по имени «\\.\C:» откроет файл тома на диске С: (предполагается, что диск С: является томом NTFS), Файл $Volume содержит также имя тома, информацию о томе и атрибуты идентификатора объекта.
$AttrDef (элемент 4) Атрибут данных $AttrDef содержит массив определений атрибута. typedef struct { WCHAR AttributeName[64]; ULONG AttributeNumber; ULONG Unknown[2]; ULONG Flags; ULONGLONG MinimumSize; ULONGLONG MaximumSize; } ATTRIBUTE_DEFINITION, *PATTRIBUTE_DEFINITION;
\ (элемент 5) Корневой каталог тома.
$Bitmap (элемент 6) Атрибут данных $Bitmap представляет собой растр кластеров тома.
$Boot (элемент 7) Первый сектор $Boot является также и первым сектором тома. Поскольку он используется в самом начале процесса загрузки системы (если том является загружаемым), то пространство здесь не нормируется, а хранимые данные не выравниваются по естественным границам. Формат первого сектора можно описать с помощью структуры BOOT_BLOCK. #pragma pack(push, 1) typedef struct { UCHAR Jump[3]; UCHAR Format[8]; USHORT BytesPerSector; UCHAR SectorsPerCluster; USHORT BootSectors; UCHAR Mbz1; USHORT Mbz2; USHORT Reserved1; UCHAR MediaType; USHORT Mbz3; USHORT SectorsPerTrack; USHORT NumberOfHeads; ULONG PartitionOffset; ULONG Reserved2[2]; ULONGLONG TotalSectors; ULONGLONG MftStartLcn; ULONGLONG Mft2StartLcn; ULONG ClustersPerFileRecord; ULONG ClustersPerIndexBlock; ULONGLONG VolumeSerialNumber; UCHAR Code[0x1AE]; USHORT BootSignature; } BOOT_BLOCK, *PBOOT_BLOCK; #pragma pack(pop)
$BadClus (элемент 8) В атрибуте данных этого файла содержится информация о сбойных кластерах.
$Secure (элемент 9) Атрибут данных $Secure содержит совместно используемые идентификаторы доступа. $Secure содержит также два индекса.
$UpCase (элемент 10) Атрибут данных $Upcase содержит эквивалент верхнего регистра всех 65536 символов Unicode.
$Extend (элемент 11) $Extend — это каталог, который содержит специальные файлы, используемые некоторыми дополнительными функциями NTFS 3.0. Специальные файлы, хранящиеся в этим каталоге, это: «$ObjId» (поддержка объектных идентификаторов), «$Quota» (поддержка квот), «$Reparse» (данные точек повторной обработки) и «$UsnJrnl» (журнал файловой системы). Начиная с Windows Vista здесь также находится каталог «$RmMetadata» (поддержка транзакций NTFS).

Хоть специальные файлы и являются на самом деле файлами, но открыть их обычным способом (например с помощью функций NtOpenFile или NtCreateFile) нельзя. Даже получив в ACL права администратора (разрешающие чтение специальных файлов), доступ к ним оказывается невозможен, поскольку для них ntfs.sys (драйвер файловой системы NTFS) всегда возвращает статус ошибки STATUS_ACCESS_DENIED. В ntfs.sys существуют две переменные, которые влияют на его поведение: NtfsProtectSystemFiles и NtfsProtectSystemAttributes. По умолчанию, значением обоих этих переменных является TRUE.

Если переменной NtfsProtectSystemAttributes присвоить значение FALSE (например с помощью отладчика), то, используя имена в формате «filename::$STANDARD_INFORMATION», можно получить доступ к атрибутам системы (в частности к стандартным информационным атрибутам). Если присвоить значение FALSE переменной NtfsProtectSystemFiles, то можно будет открыть специальные файлы. Но при попытке сделать это можно столкнуться и с некоторыми трудностями, связанными с тем, что многие из специальных файлов оказываются уже открыты системными средствами при инициализации тома, а кроме того, они не приспособлены для обработки запроса IRP_MJ_READ, возникающего при обращения к функции NtReadFile, и если такой запрос поступит, то система даст сбой. Специальные файлы можно прочесть, сделав с помощью функций NtCreateSection и NtMapViewOfSection их копии и прочитав данные из них.

Следующая проблема заключается в том, что некоторые из специальных файлов неспособны обрабатывать запрос IRP_MJ_CLEANUP, который передается тогда, когда закрывается последний дескриптор объекта файла. Если такой запрос будет получен, то произойдет сбой системы. Таким образом, необходим как минимум один открытый дескриптор специального файла, принадлежащий процессу, который никогда не завершится (например системному процессу).

См. также

Скрытое хранение данных в потоках файла $Repair в системном каталоге $RmMetadata.

По теме NTFS также есть следующее:

система комментирования CACKLE

hex.pp.ua

Надежность дисковой системы NT

Данный материал является продолжением статьи «Файловая система NTFS». В этом обзоре будут подробно рассмотрены вопросы, рассмотрение которых в прошлой статье было поверхностным или отсутствовало вообще. Хотелось бы сразу сказать, что дисковая система NT настолько сложна, что говорить о ней можно еще достаточно долго — и эта статья не опишет всего, что можно было бы рассказать. Так что это лишь попытка координировано и подробно ответить на все вопросы, которые вызвала предыдущая публикация.

Часть 4. Журналирование NTFS

Описание того простого факта, что NTFS является журналируемой системой, повергло многочисленных поклонников других файловых и операционных систем в искреннее возмущение. В многочисленных письмах, адресованных мне, NTFS называли системой с квази-журналированием или даже без журналирования вообще, ставя в противовес многочисленные файловые системы Unix. Мне пришло также много писем, указывающих на фатальные сбои NTFS, восстановится от которых не удалось — данные были потеряны. В данной части я попытаюсь, в меру своих сил и понимания, объяснить философию журналирования и средств защиты от сбоев NTFS, а также пояснить причины появления фатальных сбоев. Я постараюсь оправдать подход корпорации Microsoft, которая сделала всё именно так, как сделала — по крайней мере, я изложу причины реализованных технологических решений и те компромиссы, на которые пришлось пойти коллективу разработчиков NTFS.

Журналируемые операции

Прежде всего, хотелось бы рассказать о том, какие именно операции журналируются. Совершенно очевидно, что полный undo-файл, способный откатить абсолютно все операции, абсолютно невозможен как с точки зрения быстродействия, так и с точки зрения здравого смысла. Да, такое журналирование дало бы возможность восстановить большее число данных — например, при осуществлении перезаписи трех мегабайт в середине файла мы могли бы сначала сохранить новые данные в логе, затем переписать туда же предыдущие три мегабайта файла, и уж только затем осуществлять операции с реальными данными. Такой подход гарантировал бы полную определенность с судьбой информации — мы всегда смогли бы понять, какая часть данных уже записалась на диск, а какая находится в исходном, не обновленном состоянии. Он имеет всего один скромный недостаток — небольшая накладочка по быстродействию: для записи на диск трех мегабайт мы вынуждены будем осуществить разнообразные дисковые операции на объем в три раза больший — девять мегабайт. Да, полное журналирование также применяется — но в основном при работе с базами данных. Если вы желаете обеспечить полное журналирование каких-либо данных, вы можете поставить MS SQL или даже Oracle, который вообще не будет пользоваться средствами какой либо файловой системы и обеспечит сохранность ваших данных в любых разумных условиях. Сторонникам же полного журналирования файловой системы я могу ответить одно: решение сократить быстродействие операций записи в три раза, на мой взгляд, является слишком смелым для обязательного применения — и на домашних компьютерах, и на серверах.

Подход разработчиков NTFS был принципиально иным. Главный девиз был, видимо, не «надежность любой ценой», а «неизменность быстродействия». Журналирование просто не должно было помешать работе файловой системы. Первый логичный шаг — отменить полное журналирование как абсолютно неприемлемое с точки зрения быстродействия. В NTFS применяется журналирование логических структур, а не данных пользователя — отсюда и идет фраза, что сохранность данных не гарантируется, но, тем не менее, корректное состояние самой системы будет поддерживаться. То, что NTFS не журналирует данные файлов, приводит на практике к одному варианту потери данных — в том же гипотетическом случае записи трех мегабайт, в случае сбоя в процессе записи никогда уже не удастся установить, какая часть данных записалась, а какая осталась неизменна. Операции, которые, тем не менее, журналируются системой — это операции со структурами самой системы, то есть с файлами и каталогами: добавление файлов, переименование, перенос, создание и удаление (освобождение свободного места). Журналируются также и операции дефрагментации — то есть перемещения фрагментов файлов. Одним словом, все логические операции журналированы.

Отложенная запись и контрольные точки журналирования

Известно, что любая современная система для ускорения файловых операций вынуждена использовать кэширование, в том числе — кэширование операций записи. Так называемая отложенная запись — принцип кэширования, при котором данные, предназначенные для записи на диск, некоторое время сохраняются в кэше и лишь в свободное от других занятий время сохраняются физически. Отложенная запись существенно повышает эффективность дисковых операций, так как такое кэширование группирует множество операций в одну — это особенно эффективно, если запись производится в компактные участки диска. Еще один плюс отложенной записи — не мешать более нужным операциям чтения, и осуществлять запись только тогда, когда система свободна и ей не требуется доступ к диску для других нужд. Как согласовать отложенную запись с журналированием? Это довольно сложный вопрос, так как откладывание записи делает возможным потерю тех данных, которые находились в очереди на физическую запись и не успели записаться на диск до сбоя. Самое неприятное здесь даже не потеря данных, а то, что происходит рассогласование времени записи: какие-то служебные области могут быть обновлены, а какие-то смежные по смыслу — еще нет, так как их обновление могло отложится еще на пару секунд и не состоятся из-за сбоя.

NTFS справляется с этими проблемами с помощью смысловой интеграции операций отложенной записи и ведения журнала. При попытке начать журналируемую операцию в лог тут же записывается намерение — например, стереть файл. Это случается без задержек — на этом этапе отложенная запись не работает: это плата за присутствие журналирования, которой нельзя избежать. Но вот все остальные операции уже идут в задержанном режиме — то есть они могут состояться частично (могут еще в придачу и не в том порядке) или не состоятся вообще. Единственная задержанная операция, работа которой несколько отличается от простой записи — запись в лог об удачном завершении предыдущих транзакций, так называемая контрольная точка. Через определенные промежутки времени — обычно через каждые несколько секунд — система в обязательном порядке сбрасывает абсолютно все задержанные операции на диск. После произведения этой операции в журнал записывается простейшая запись — контрольная точка — которая говорит о том, что все предыдущие операции выполнены корректно на всех уровнях — как на логическом, так и на физическом.

Такой режим работы — с помощью записей и контрольных точек — с одной стороны, по прежнему гарантирует полностью корректную работу журналирования, а с другой стороны практически совершенно не приводит к замедлению работы: простановка контрольных точек производится, считай, мгновенно, а запись в журнал о начале операции соответствует по трудозатратам записи самих данных без отложенного кэширования. Реальная же запись, осуществляемая позже, в подавляющем числе случаев не мешает никаким операциям и не идет в ущерб производительности системы.

Проблемы отложенного журналирования: концепция дублирования информации

Вся вышеописанная теория достаточно хороша, но способна, тем не менее, вызвать очень неприятные последствия, если не учесть еще нескольких вещей, о которых и пойдет речь.

Рассмотрим такой случай: мы стираем файл. Журнал получил запись — «файл N стирается». Затем запаздывающему кэшу стало угодно осуществить сначала физическую пометку о том, что место, занимаемое файлом, освободилось, а уж только затем удалить файл из физических структур MFT и каталога. Допустим, диск находится в активной работе, и на освободившееся место тут же записывается другой файл. В этот момент происходит сбой. Система, загружаясь, исследует журнал и видит незавершенную операцию «файл N стирается» — вернее, как я уже описал выше, не незавершенную, а просто операцию, контрольная точка после которой отсутствует, что автоматически говорит о её незавершенности. Следующая фаза была бы «откат операции» — то есть восстановление файла. Одна незадача — место, физически занимаемое файлом, содержит уже другие данные.

Для недопущения таких ситуаций система, желающая ограничиться логическим журналированием, вынуждена применять принцип «временно занятого места». Место, освобожденное каким-либо объектом или записью о нем, не объявляется свободным до тех пор, пока физически не завершились все операции с логическими структурами. Данный механизм в NTFS, по видимому, не синхронизирован даже с проставлением контрольных точек, так как типичное время освобождения временно занятого места — около 30 секунд, точки же идут чаще.

Данный механизм применяется не только при стирании файла, но и при самых разных операциях: принцип журналирования — объект, убранный или перемещенный на новое место, должен иметь возможность корректно откатить своё «отбытие» — то есть данные, на которые ссылаются логические структуры удаляемого или перемещаемого объекта, необходимо еще на некоторое время зарезервировать как занятое место (диска/каталога). Это еще один шаг NTFS к полному журналированию, где специфическим журналом файловой информации служат сами данные освобождаемых областей, не уничтожаемые физически.

Допущения, обеспечивающие надежность

Ну хорошо, скажете вы, всё так замечательно — но почему же тогда разделы NTFS всё же летят?.. Сейчас я постараюсь объяснить принципы, которые приводит к тому, что вышеописанная модель сможет обеспечить полную восстанавливаемость логических структур.

Жесткий диск, в штатном режиме, должен записать именно то и именно туда, что и куда ему сказано было записать операционной системой. Данный принцип нарушается в случае, если система имеет ненадежный шлейф, процессор, память или контроллер — и это самая распространенная причина сбоев NTFS. Вам поможет: неразогнанный процессор, дорогая (качественная) память, хорошая материнская плата и протокол UDMA, обеспечивающий контроль и восстановление ошибок на участке контроллер-диск.
Жесткий диск, в случае аварии, отключения питания или получения от контроллера сигнала «сброс» (в случае внезапной перезагрузки материнской платы) обязан корректно завершить запись данных текущего физического сектора, если таковая производилась на момент аварии. Промежуточное состояние сектора не допускается. Вам помогут современные винчестеры, которые могут осуществить данную операцию даже в случае полного пропадания питания — у них хватит буферизированной в конденсаторах энергии, и их логика рассчитана на корректное поведение в случае отказа питания при записи.
Диск обязан мгновенно осуществить запись данных, отправленных с флагом «не кэшировать». Дело в том, что многие современные диски или контроллеры обеспечивают задержанную запись. Метафайлы NTFS обновляются в режиме «писать сразу», и контроллер/диск обязан выполнять это требование.
Жесткий диск обязан обеспечить чтение именно тех данных, которые были записаны. В случае невозможности прочесть данные выдается сигнал «ошибка». Диск не имеет права возвращать ошибочные данные (возможно, лишь частично некорректные) без сигнала об ошибке. Все современные жесткие диски имеют контрольные суммы секторов и жестко следуют этой логике поведения.

Четкое выполнение этих требований полностью гарантирует надежную работу NTFS. Структура файловой системы не будет содержать существенных ошибок даже после сбоя. Некоторые несущественные ошибки всё же появляются из-за того, что логика журналирования часто пытается завершить недоделанные операции — например, то же удаление файла — тогда как полную надежность обеспечивал бы только безусловный откат всего, что находится после последней контрольной точки. Малые несоответствия, рождающиеся из этих попыток, относятся к избыточной информации системы безопасности, не представляют никакой реальной опасности для данных — они действительно незначительны. Суть этих несоответствий чаще всего заключается в том, что на диске остаются «лишние» данные о тех режимах доступов, которые уже не понадобятся системе. Их прочистка — дело сугубо повышения производительности, как, например, дефрагментация, поэтому их наличие не является на самом деле ошибкой. В случае же обнаружения серьезных, реальных, проблем драйвер сам установит флажок тома «грязный», что проинструктирует систему проверить том при следующем его монтировании.

Я с большим сожалением должен сказать, что подавляющее большинство фатальных ошибок NTFS происходит по вине аппаратуры, не выполняющей эти элементарные требования. Да, я понимаю, абсолютной надежности не бывает. Но Microsoft пошел по пути разделения труда — за надежность вашей аппаратуры корпорация ответственности не несет. Мой компьютер на 70% не попадает в список совместимого с Windows 2000 оборудования, и то же самое можно сказать про почти любую реальную машину, функционирующую на просторах бывшего СССР. Особенно это относится к любителям разгонять компьютеры. Запомните раз и навсегда: вы с огромной степенью вероятности угробите NTFS в первый же год работы, если ваш процессор — 333, разогнанный на 415. И даже не раз... Мне очень жаль, но это действительно так. От любых сбоев корректного компьютера NTFS защитит, но вот от записи случайных данных в бут-сектор (копия которого, кстати, хранится в самом конце раздела) и в MFT система просто не страхуется. Извините.

Часть 5. Программный RAID

Журналирование NTFS, как уже указывалось ранее, ни в коей мере не гарантирует от сбоев с потерей пользовательской информации. Между тем, NT предлагает несколько вариантов создания систем, где, в разумных условиях, гарантируется абсолютно всё. Можно также использовать большее число дисков для обеспечения не повышенной надежности, а, наоборот, повышенной скорости — или того и другого одновременно. О таких конфигурациях и пойдет речь в этой части статьи.

RAID (Redundant Array of Inexpensive Disks) — избыточный массив недорогих дисков. Технология, заключающаяся в одновременном использовании нескольких дисковых устройств для обеспечения характеристик надежности или скорости, отсутствующих у накопителей в отдельности.

Windows NT поддерживает на программном уровне три уровня RAID (так называются стратегии работы дисковых массивов), краткие характеристики которых сведены в следующую таблицу.

	Быстродействие, по сравнению с обычными дисками	Надежность	Общее дисковое пространство
RAID 0Параллельные дискиСущественное повышение производительности за счет дублирования дисков.	Теоретически, в условиях некоторых (например, линейных) операций скорость чтения/записи, повышается во столько раз, сколько дисков задействовано в системе.Реально увеличение быстродействия меньше — процентов 50%-90% от этого числа, что всё равно очень существенно.	Понижается — фатальный сбой одного из дисков вызовет потерю данных.	Равно сумме объемов составляющих массив дисков
RAID 1 Зеркальные дискиПовышение надежности за счет дублирования информации.	Скорость чтения теоретически повышается в число раз, соответствующее числу дисков. Реализованный в NT алгоритм не оптимален и приводит к гораздо более скромному увеличению быстродействия.Скорость записи снижается, особенно в случае не до конца многозадачных дисковых контроллеров.	Потеря данных возможна лишь в случае отказа сразу всех дисков или повреждения одного и того же участка информации на всех дисках.	Остается неизменным (увеличение доступного дискового пространства за счет добавочных дисков не происходит).
RAID 5Параллельные диски с четностьюКомбинация RAID 1 и RAID 0 — более эффективное использование дополнительных дисков.	Скорость чтения повышается аналогичным RAID 0 образом, но число дисков, влияющих на быстродействие, следует уменьшить на один. Т.е. три диска RAID 5 обладают примерно такой же скоростью чтения, как и два диска RAID 0.Скорость записи больше, чем у каждого диска в отдельности, но в целом невысока.	Потеря данных возможна при выходе из строя двух дисков набора. Выход из строя одного из дисков существенно снижает скорость работы всего массива и является, по сути, аварийной ситуацией, хоть и без потери данных.	Увеличивается.Потеря от суммарного дискового объема составляет объем одного диска.Например, пять дисков по 10 Гб дают RAID 5 объемом 40 Гб.

Остановимся подробнее на каждом из типов RAID-а.

RAID 0 (параллельные диски)

Данная стратегия направлена исключительно на повышение производительности. Несколько дисков хранят части дисковой структуры, которые собираются в один том лишь при наличии всех дисков массива.

Простейшая реализация RAID 0 из двух, например, дисков — указание на то, что каждый первый сектор тома (или любой другой объем информации) расположен на физическом диске A, а каждый второй — на диске B. Такая жесткая стратегия дает возможность избежать каких-либо дополнительных структур для хранения информации о том, где находятся какие данные. Скорость чтения, как и записи равны и зависят от числа дисков:

Быстродействие операции по работе со случайно расположенными данными подчиняются следующей схеме: всё зависит от вероятности того, что диск, на который мы хотим записать очередную порцию информации, свободен и готов мгновенно выполнить наш запрос. Например, RAID 0 из двух дисков: при осуществлении операции одним из дисков и поступлении дополнительной команды на работу с дисковой системой вероятность того, что для выполнения команды нам придется тревожить свободный в данный момент диск составляет 50% — это соответствует общему увеличению производительности случайных операций в полтора раза. Если же используется, к примеру, массив из десяти дисков, то вероятность какой-либо операции попасть на уже занятый накопитель составляет всего 10% — то есть производительность повышается в девять раз. Любителям строгой теории вероятности хочу заметить, что при таких подсчетах не учитываются некоторые факторы реальной работы систем, но цифры, тем не менее, имеют именно такой порядок.
Последовательные операции — чтение или запись последовательных участков — проходят практически всегда в n раз быстрее, чем на отдельном физическом диске, где n — число дисков в наборе. Это происходит потому, что вероятность в следующей операции попасть на свободный диск составляет 100% — ведь операции осуществляются последовательными блоками, которые равномерно раскидываются по дискам.

В качестве некоторого вывода — RAID 0 в любом случае существенно повышает быстродействие линейных операций, а с увеличением количества дисков, входящих в набор, существенно повышается скорость работы и со случайными данными. Для эффективной работы с дисковой системой в режиме RAID 0 просто необходим многозадачный режим работы контроллера, а желательно даже разных контроллеров, обеспечивающих доступ к разным дискам. Обязательным условием такой работы на интерфейсах IDE являются Bus-Mastering драйвера. Windows 2000 имеет встроенные драйвера, автоматически включающие этот режим для всех распространенных 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) Disk Administrator, где, собственно, и создаются эти типы дисков. Обращаю ваше внимание, что способности рабочих станций в создании и использовании RAID-ов сильно ограничены — рабочая станция NT4, к примеру, поддерживает только RAID 0 (параллельные диски), тогда как все описанные варианты работают лишь на серверных вариантах операционных систем.

Часть 6. Стратегия восстановления томов NTFS

Компьютер с NTFS не загружается. Что делать в этом случае? Как восстановить данные? Возможны два случая, действия в которых несколько отличаются друг от друга. К сожалению, простых стратегий восстановления NT и, соответственно, NTFS не существует — система достаточно сложна и не имеет простейших загрузочных средств, как, например, DOS или Windows95/98.

1. Первый вариант — система находилась на том же 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, прошедшую преобразование в новый формат от Windows2000. NT4 всё же читает такой NTFS, но только при наличии пакета обновления SP4 или выше.

Пользователи Windows2000 будут вынуждены найти загрузочный CD диск с Windows2000 (таким является официальный дистрибутив), который сам предложит вам либо поставить систему с нуля, или попытаться восстановить старую инсталляцию. Считать диск NTFS, с которым работал Windows2000, можно только самим Windows2000 или NT4 с пакетом обновления SP4 или выше.

Имейте в виду: восстановить какую-либо NT, не обладая либо диском аварийного восстановления (создается в NT4 командой rdisk /s, в Windows2000 — программой резервного копирования), практически невозможно — это работа для специалиста. К слову говоря, даже при наличии диска восстановления, вам скорее всего очень не понравится работа «восстановленной» системы, поэтому переустановка всей системы практически неизбежна. Если вы не являетесь опытным специалистом по NT, советую вам не пытаться пользоваться починяющими опциями установщика NT, т.к. результат вас, скорее всего, крайне не удовлетворит. Попытка, конечно, не пытка, но комплекс операций по полноценной реанимации системы очень велик и мало где описан, поэтому вы останетесь в каком-то промежуточном, хотя, наверное, и загружабельном, состоянии.

2. Система сама по себе работает, но доступа к диску (не загрузочному, а какому-то другому) нет. Disk Administrator показывает для вашего раздела тип unknown (неизвестный). В подавляющем большинстве случаев это означает, что каким-то образом была осуществлена перезапись загрузочной области (boot sector-а) раздела, и NT действительно не догадывается, что это вообще NTFS. Операционная система NT на всякий случай хранит копию загрузочного сектора в конце раздела — если его скопировать обратно в надлежащее место, в подавляющем большинстве случаев диск опознается как NTFS и починится самостоятельно.

Процесс вычисления правильных адресов достаточно сложен, поэтому я не буду его описывать. Для получения исчерпывающих инструкций для данного случая вам придется пойти на сайт MSDN и найти там статью Knowledge Base под номером Q153973 (скорее всего, вы сможете сделать это простым поиском) — после корректного следования этим инструкциям система по крайней мере опознается как NTFS, и дальнейшая судьба раздела зависит от внутренних средств восстановления NT, которые в таком случае возьмут его в оборот. Вам также поможет скромная на вид команда chkdsk, являющаяся неким ярлычком к системе внутреннего восстановления дисковых систем NT.

www.ixbt.com

Структура тома с файловой системой NTFS

⇐ ПредыдущаяСтр 25 из 50Следующая ⇒

Всё дисковое пространство в NTFS делится на две неравные части (рис.4.12). Первые 12 % диска отводятся под так называемую MFT-зону – пространство, которое может занимать, увеличиваясь в размере, главный служебный метафайл MFT2. Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой – это делается для того, чтобы самый главный, служебный файл (MFT) по возможности не фрагментировался при своем росте. Остальные 88 % тома представляют собой обычное пространство для хранения файлов.

Рис.4.12. Структура тома NTFS

MFT (master file table, общая таблица файлов) представляет собой централизованный каталог всех остальных файлов диска, в том числе и себя самого. MFT поделен на записи фиксированного размера в 1 Кбайт1, и каждая запись соответствует какому-либо файлу (в общем смысле этого слова). Первые 16 файлов носят служебный характер и недоступны операционной системе – они называются метафайлами, причем самый первый метафайл – сам MFT. Эти первые 16 элементов MFT – единственная часть диска, имеющая строго фиксированное положение. Копия этих же 16 записей хранится в середине тома для надёжности, поскольку они очень важны. Остальные части MFT-файла могут располагаться, как и любой другой файл, в произвольных местах диска – восстановить его положение можно с помощью его самого, «зацепившись» за самую основу – за первый элемент MFT.

Таблица 4.7. Метафайлы NTFS

Имя метафайла	Назначение метафайла
$MFT	Сам Master File Table
$MFTmirr	Копия первых 16 записей MFT, размещенная посередине тома
$LogFile	Файл поддержки операций журналирования
$Volume	Служебная информация – метка тома, версия файловой системы и т. д.
$AttrDef	Список стандартных атрибутов файлов на томе
$.	Корневой каталог
$ Bitmap	Карта свободного места тома
$Boot	Загрузочный сектор (если раздел загрузочный)
$Quota	Файл, в котором записаны права пользователей на использование дискового пространства (этот файл начал работать лишь в Windows 2000 с системой NTFS 5.0)
$Upcase	Файл – таблица соответствия заглавных и прописных букв в именах файлов. В NTFS имена файлов записываются в Unicode (что составляет 65 тысяч различных символов) и искать большие и малые эквиваленты в данном случае – нетривиальная задача

Файл в томе с NTFS идентифицируется так называемой файловой ссылкой (File Reference), которая представляется как 64-разрядное число. Файловая ссылка состоит из номера файла, который соответствует позиции его файловой записи в MFT, и номера последовательности. Последний увеличивается всякий раз, когда данная позиция в MFT используется повторно, что позволяет файловой системе NTFS выполнять внутренние проверки целостности.

Каждый файл в NTFS представлен с помощью потоков (streams), то есть у него нет как таковых «просто данных», а есть «потоки». Для правильного понимания потока достаточно указать, что один из потоков и носит привычный нам смысл – данные файла. Но большинство атрибутов файла – это тоже потоки. Таким образом, получается, что базовая сущность у файла только одна – номер в MFT, а всё остальное, включая и его потоки, – опционально. Данный подход может эффективно использоваться – например, файлу можно «прилепить» ещё один поток, записав в него любые данные. В Windows 2000 таким образом записана информация об авторе и содержании файла (одна из закладок в свойствах файла, просматриваемых, например, из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами работы с файлами: наблюдаемый размер файла – это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длины, при стирании которого освободится 1 Гбайт свободного места – просто потому, что какая-нибудь хитрая программа или технология «прилепила» к нему дополнительный поток (альтернативные данные) такого большого размера. Но на самом деле в настоящее время потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны1. Просто необходимо иметь в виду, что файл в NTFS – это более глубокое понятие, чем можно себе представить, просматривая каталоги диска.

Таблица 4.8. Атрибуты файлов в системе NTFS

Системный атрибут	Описание атрибута
Стандартная информация о файле	Традиционные атрибуты Read Only, Hidden, Archive, System, отметки времени, включая время создания или последней модификации, число каталогов, ссылающихся на файл
Список атрибутов	Список атрибутов, из которых состоит файл, и файловая ссылка на файловую запись и MFT, в которой расположен каждый из атрибутов. Последний используется, если файлу необходимо более одной записи в MFT
Имя файла	Имя файла в символах Unicode. Файл может иметь несколько атрибутов – имён файла, подобно тому как это имеет место в UNIX-Системах. Это случается, когда имеется связь POSIX с данным файлом или если у файла есть автоматически сгенерированное имя в формате 8.3
Дескриптор защиты	Структура данных защиты (ACL), предохраняющая файл от несанкционированного доступа. Атрибут «дескриптор защиты» определяет, кто владелец файла и кто имеет доступ к нему
Данные	Собственно данные файла, его содержимое. В NTFS у файла по умолчанию есть один безымянный атрибут данных, и он может иметь дополнительные именованные атрибуты данных. У каталога нет атрибута данных по умолчанию, но он может иметь необязательные именованные атрибуты данных
Корень индекса, размещение индекса, битовая карта (только для каталогов)	Атрибуты, используемые для индексов имён файлов в больших каталогах
Расширенные атрибуты HPFS	Атрибуты, используемые для реализации расширенных атрибутов HPFS для подсистемы OS/2 и OS/2–клиентов файл-серверов Windows NT

Атрибуты файла в записях MFT расположены в порядке возрастания числовых значений кодов типа, причем некоторые типы атрибутов могут встречаться в записи более одного раза: например, если у файла есть несколько атрибутов данных или несколько имен. Обязательными для каждого файла в томе NTFS являются атрибут стандартной информации, атрибут имени файла, атрибут дескриптора защиты и атрибут данных. Остальные атрибуты могут встречаться при необходимости.

Имя файла в NTFS, в отличие от файловых систем FAT и HPFS, может содержать любые символы, включая полный набор национальных алфавитов, так как данное представлены в Unicode – 16-битном представлении, которое дает 65 535 разных символов. Максимальная длина имени файла в NTFS – 255 символов.

Заметим, что добавлять файл в каталог в виде дерева не намного труднее, чем в линейный каталог системы FAT. Это сопоставимые по времени операции. Для того чтобы добавить новый файл в каталог, нужно сначала убедиться, что файла с таким именем там ещё нет. Поэтому в системе FAT с линейной организацией записей каталога у нас появляются трудности не только с поиском файла. И это с лихвой компенсирует саму простоту добавления файла в каталог.

Структура тома NTFS

В отличие от разделов FAT и s5/ufs все пространство тома' NTFS представляет собой либо файл, либо часть файла. Основой структуры тома NTFS является главная таблица файлов (Master File Table, MFT), которая содержит, по крайней мере, одну запись для каждого файла тома, включая одну запись для самой себя. Каждая запись MFT имеет фиксированную длину, зависящую от объема диска, — 1, 2 или 4 Кбайт. Для большинства дисков, используемых сегодня, размер записи MFT равен 2 Кбайт, который мы далее будет считать размером записи по умолчанию.

Все файлы на томе NTFS идентифицируются номером файла, который определяется позицией файла в MFT. Этот способ идентификации файла близок к способу, используемому в файловых системах s5 и ufs, где файл однозначно идентифицируется номером его записи в области индексных дескрипторов.

Весь том NTFS состоит из последовательности кластеров, что отличает эту файловую систему от рассмотренных ранее, где на кластеры делилась только область данных. Порядковый номер кластера в томе NTFS называется логическим номером кластера (Logical Cluster Number, LCN). Файл NTFS также состоит из последовательности кластеров, при этом порядковый номер кластера внутри файла называется виртуальным номером кластера (Virtual Cluster Number, VCN).

Базовая единица распределения дискового пространства для файловой системы NTFS — непрерывная область кластеров, называемая отрезком. В качестве адреса отрезка NTFS использует логический номер его первого кластера, а также количество кластеров в отрезке к, то есть пара (LCN, к). Таким образом, часть файла, помещенная в отрезок и начинающаяся с виртуального кластера VCN, характеризуется адресом, состоящим из трех чисел: (VCN, LCN, к). Для хранения номера кластера в NTFS используются 64-разрядные указатели, что дает возможность поддерживать тома и файлы размером до 2м кластеров. При размере кластера в 4 Кбайт это позволяет использовать тома и файлы, состоящие из 64 миллиардов килобайт.

Структура тома NTFS : Загрузочный блок тома NTFS располагается в начале тома, а его копия — в середине тома. Загрузочный блок содержит стандартный блок параметров BIOS, количество блоков в томе, а также начальный логический номер кластера основной копии MFT и зеркальную копию MFT. Далее располагается первый отрезок MFT, содержащий 16 стандартных, создаваемых при форматировании записей о системных файлах NTFS. Назначение этих файлов описано в показанной ниже таблице MFT.

Номер записи	Системный файл	Имя файла	Назначение файла
	Главная таблица файлов	$MFT	Содержит полный список файлов тома
	Копия главной таблицы файлов	$MFTMirr	Зеркальная копия первых 3-х записей MFT
	Файл журнала	$Logfile	Список транзакций, который используется для восстановления файловой системы после сбоев
	Том	$Volume	Имя, версия тома и др. информация
	Таблица определения атрибутов	$AttrDef	Таблица имен, номеров и описаний атрибутов
	Индекс корневого каталога	$	Корневой каталог
	Битовая карта кластеров	$Bitmap	Разметка использования кластеров тома
	Загрузочный сектор раздела	$Boot	Адрес загрузочного сектора раздела
	Файл плохих кластеров	$BadClus	Файл, содержащий список всех обнаруженных на томе плохих кластеров
	Таблица квот	$Quota	Квоты используемого пространства на диске для каждого пользователя
	Таблица преобразования регистра символов	$Upcase	Используется для преобразования регистра символов для кодировки Unicode
11-15	Зарезервировано

В NTFS файл целиком размещается в записи таблицы MFT, если это позволяет сделать его размер. В том же случае, когда размер файла больше размера записи MFT, в запись помещаются только некоторые атрибуты файла, а остальная часть файла размещается в отдельном отрезке тома (или нескольких отрезках). Часть файла, размещаемая в записи MFT. называется резидентной частью, а остальные части — нерезидентными. Адресная информация об отрезках, содержащих нерезидентные части файла, размещается в атрибутах резидентной части.

Некоторые системные файлы являются полностью резидентными, а некоторые имеют и нерезидентные части, которые располагаются после первого отрезка MFT.

Нулевая запись MFT содержит описание самой MFT, в том числе и такой ее важный атрибут, как адреса всех ее отрезков. После форматирования MFT состоит из одного отрезка, но после создания первого же несистемного файла для хранения его атрибутов требуется еще один отрезок, так как изначально непрерывная последовательность кластеров MFT уже завершена системными файлами.

Из приведенного описания видно, что сама таблица MFT рассматривается как файл, к которому применим метод размещения в томе в виде набора произвольно расположенных нескольких отрезков.

Это интересно

Опрос

Полезные ссылки

Поиск по сайту

Структура тома с файловой системой NTFS. Журнал тома ntfs

Структура тома с файловой системой ntfs

Команда fsutil USN | Энциклопедия Windows

Специальные файлы NTFS

См. также

По теме NTFS также есть следующее:

Надежность дисковой системы NT

Часть 4. Журналирование NTFS

Журналируемые операции

Отложенная запись и контрольные точки журналирования

Проблемы отложенного журналирования: концепция дублирования информации

Допущения, обеспечивающие надежность

Часть 5. Программный RAID

RAID 0 (параллельные диски)

RAID 1 (зеркальные диски)

RAID 5 (параллельные диски с четностью)

Допущения, обеспечивающие надежность

Часть 6. Стратегия восстановления томов NTFS

Структура тома с файловой системой NTFS

Структура тома NTFS

Похожие статьи:

Смотрите также