Хранение файлов и каталогов.

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

Нерезидентное хранение: Конечно, в большинстве случаев все данные файла не помещаются в запись MFT, поэтому этот атрибут, как правило, является нерезидентным. Файл без фрагментации описывается всего одной записью (стартовый кластер, число кластеров).

 

Нерезидентное хранение файлов среднего размера:

На рисунке файл состоит из 3-х серий кластеров: 20 – 23, 64 – 65, 80 – 82. Число таких серий зависит от того насколько удачно ФС сумела найти место для хранения файла.

 

 

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

 

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

Внутренняя структура каталога представляет собой бинарное B+ дерево (форма двоичного дерева, каждый узел которого может иметь более двух дочерних узлов), элементы которого сортируются по имени.

Для поиска файла с данным именем в линейном каталоге, таком, например, как у FAT-а, системе приходится просматривать все элементы каталога, пока она не найдет нужный. Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся более быстрым способом - с помощью получения двухзначных ответов на вопросы о положении файла. Вывод – для поиска одного файла среди 1000, например, FAT придется осуществить в среднем 500 сравнений (наиболее вероятно, что файл будет найден на середине поиска), а системе на основе дерева - всего около Log2(N), т.е. 10-ти (2^10 = 1024).

 

Небольшие записи каталогов находятся полностью внутри структуры MFT так же, как записи файла (копии атрибута File_Name файлов и подкаталогов). Для хранения используется атрибут $Index_Root (корневой индекс), который всегда резидентный!

В том случае, когда каталог не умещается целиком в MFT, требуется выделение дополнительного пространства:

корневой индекс хранит корень дерева B+ со ссылками на нерезидентные индексные буферы;

для хранения описания файлов выделяются нерезидентные индексные буферы (4 Кбайт), каждый из которых адресуется с использованием виртуального номера кластера (virtual clusters numbers, VCN) для сквозной нумерации кластеров в рамках одной записи MFT;

соответствие между VCN и LCN (logical clusters numbers) хранится в атрибуте каталога $Index_Allocation.

 

Резидентное хранение (запись MFT):

 

 

Нерезидентное хранение (запись MFT):

 

 

 

Запись MFT для небольшого каталога содержит несколько записей, каждая из которых описывает файл или каталог.

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

 

 

 

Рассмотрим ситуацию открытия файла e.bak.

 

l Первоначально NTFS читает атрибут индексного корня $INDEX_ROOT, содержащий элементы для d.new, h.txt и i.doc, и сравнивает строку e.bak с именем первого элемента, d.new.

l Далее NTFS делает вывод, что алфавитный номер e.bak больше, чем d.new, и переходит к следующему элементу – h.txt.

l Повторив операцию сравнения, NTFS выясняет, что алфавитный номер e.bak меньше, чем h.txt.

l Затем NTFS отыскивает в $INDEX_ROOT номер виртуального кластера VCN индексного буфера, содержащего элементы каталога, алфавитные номера которых меньше, чем h.txt, но больше, чем d.new. VCN представляет собой порядковый номер кластера в файле или каталоге.

l На основании информации о размещении кластеров, хранящейся в $INDEX_ALLOCATION, файловая система преобразует VCN в логический номер кластера LCN, т. е. номер кластера относительно начала тома.

l Получив LCN начального кластера индексного буфера, NTFS читает буфер размещения индексов и просматривает его в поисках совпадений.

l Если элемент индексного буфера для h.txt не содержит файла e.bak, то NTFS сообщает о неудачном завершении поиска.

l На рисунке первый же элемент индексного буфера совпадает с критерием поиска, и NTFS читает номер записи MFT e.bak.

 

 

6. Сжатие файлов в NTFS. Файловая система NTFS поддерживает прозрачное сжатие файлов. Сжатие файлов производится следующим образом.

l Когда файловая система NTFS записывает на диск файл, помеченный для сжатия, она изучает первые 16 кластеров. Затем к этим кластерам применяется алгоритм сжатия.

l Если полученные на выходе данные могут поместиться в 15 или менее кластеров, то сжатые данные записываются на диск, предпочтительно в виде одной серии.

l Если получить выигрыш не получается, то группа из16 кластеров записывается без сжатия.

l Затем алгоритм повторяется для группы следующих 16 кластеров и т.д.

 

Сжатие файла частями по 16 кластеров явилось компромиссом, если бы порции были меньше, то эффективность бы сжатия снизилась. Если размер порции был бы больше, то это замедлило бы произвольный доступ.

 

Показан файл, в котором первые 16 блоков успешно сжаты в 8 блоков, следующие 16 не могут быть сжаты, наконец, последние 16 блоков также успешно сжаты на 50%. Эти три части файла записаны в виде трех сегментов, информация о которых хранится в записи MFT. “Пропущенные” блоки обозначаются в записи MFT как сегменты с нулевым дисковым адресом. На слайде за заголовком (0,48) следует 5 пар, две для первого (сжатого) сегмента, одна для несжатого и две для последнего (сжатого) сегмента. При чтении этого файла система NTFS должна знать, какие из сегментов файла сжаты, а какие нет. Она видит это по дисковым адресам. Дисковый адрес 0 указывает на то, что предыдущий сегмент сжат. Дисковый блок 0 не может использоваться для хранения данных во избежание неоднозначности (это загрузочный сектор). Произвольный доступ к сжатому файлу возможен, но не прост. Например, для чтения блока 35 необходимо определить где находится этот блок и распаковать весь сегмент.

 

Разреженные файлы:

Другой тип сжатия известен как разреженные файлы. Если у вас есть файлы, которые содержат множество нулей (попросту говоря в файле есть "пустые области"), то NTFS позволяет сохранять пространство диска, давая таким файлам определение sparse (разреженный). Так вот при сохранении таких файлов система просто не выделяет место для пустых областей файла - в результате чего и достигается уменьшение размера файла. При обращении системы к частям, отмеченным как пустые, NTFS просто возвращает нулевые значения. При просмотре свойств файла система сообщит о зарезервированном для него размере, хотя фактический объем может занимать в сотни тысяч раз меньший объем. Разреженные файлы применяются, в частности, в журнале NTFS ($LogFile).

Разреженные файлы конвертируются с помощью следующей команды: fsutil sparse.

Защита целостности данных.

Система восстановления NTFS гарантирует корректность файловой системы, а не ваших данных.

 

NTFS является восстанавливаемой ФС и поддерживает следующие технологии защиты целостности данных:

Тома с аппаратной или программной поддержкой RAID 0, RAID 4, RAID 5 и пр.

Горячая фиксация – позволяет файловой системе при возникновении ошибки из-за плохого кластера записать информацию в другой кластер и отметить сбойный в качестве плохого.

Механизм транзакций – каждая операция ввода-вывода, которая изменяет файл на разделе NTFS, рассматривается файловой системой как транзакция и может выполняться только как неделимый блок.

Восстанавливаемость файловой системы в NTFS обеспечивается при помощи техники обработки транзакций, называемой протоколированием (logging). В процессе протоколирования, прежде чем выполнить над содержимым диска какую-либо подоперацию транзакции, изменяющей важные структуры файловой системы, NTFS записывает ее в файл журнала транзакций. При восстановлении после сбоя системы NTFS просматривает журнал и повторяет все подтвержденные транзакции. После повтора всех подтвержденных транзакций NTFS отыскивает в журнале такие, которые не были подтверждены к моменту сбоя, и откатывает (отменяет) каждую запротоколированную подоперацию.

Примеры транзакций:

l создание файла

l удаление файла

l расширение файла

l урезание файла

l установка файловой информации

l переименование файла

l изменение прав доступа к файлу

 

 

В состав средств протоколирования NTFS входят следующие компоненты:

l журнал транзакций (log file) – это системный файл, создаваемый командой format;

l сервис журнала операций (log file service, LFS) – набор системных процедур, которые NTFS использует для доступа к журналу транзакций, например, для открытия файла журнала, помещения в журнал записей, считывания записей журнала в прямом и в обратном порядке, сброса записей журнала и т.д. NTFS никогда не выполняет чтение-запись транзакций в журнал напрямую.

l диспетчер кэша (cache manager) – это системный компонент Windows, поддерживающий кэширование для NTFS и драйверов других файловых систем (FAT32).

 

 

Файл журнала состоит из двух частей:

l область рестарта (restart area) – в этой области NTFS хранит информацию о том, откуда начинать чтение области протоколирования при восстановлении после сбоя системы. Для повышения отказоустойчивости LFS создает копию области рестарта.

l область протоколирования (logging area) – в которой находятся записи транзакций, обеспечивающие NTFS восстановление после сбоя. LFS создает иллюзию бесконечности журнала транзакций путем ее циклического повторного использования с использованием механизма разреженных файлов.

Для идентификации записей, помещенный журнал, LFS использует номера логической последовательности (logical sequence number, LSN).

В файле журнала различают 3 вида записей:

l записи модификации (большинство записей в журнале транзакций – записи модификации);

Структура записи модификации:

l Информация для повтора (redo info)

как вновь применить к тóму одну подоперацию полностью запротоколированной транзакции, если сбой системы произошел до того, как транзакция была переписана из кэша на диск.

l Информация для отмены (undo info)

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

l записи подтверждения транзакции;

после протоколирования транзакции NTFS выполняет ее подоперации непосредственно над томом – в кэше. По окончании обновления кэша NTFS помещает в журнал еще одну запись – подтверждение транзакции (committing a transaction). После того как транзакция подтверждена, NTFS гарантирует, что все вызванные ею модификации будут отражены на томе, даже если после подтверждения произойдет сбой системы.

l записи контрольной точки.

Периодически (5 сек.) NTFS помещает в журнал транзакций записи контрольной точки: запись контрольной точки помогает NTFS определить, какая обработка необходима для восстановления тома, если сбой произошел “сразу” после помещения этой записи в журнал. LSN контрольной точки записывается в область рестарта.

Контрольная точка содержит две таблицы восстановления:

l Таблица транзакций (transaction table) предназначена для отслеживания транзакций, которые были начаты, но еще не подтверждены. Их надо удалить в процессе восстановления.

l В таблицу измененных страниц (dirty page table) записывается информация о том, какие изменения структуры файловой системы еще не записанные на диск. Эти данные в процессе восстановления должны быть сброшены на диск.

 

При восстановлении тома NTFS загружает журнал транзакций в оперативную память и выполняет три прохода:

l анализ;

l повтор транзакций;

l сканирование журнала транзакций в прямом направлении, начиная с LSN самой старой записи, которая была обнаружена на проходе анализа;

l поиск записей "обновление страницы", содержащие модификации тома, которые были запротоколированы до сбоя системы, но не сброшены из кэша на диск;

l повторение найденных обновлений в кэш.

l отмена транзакций.

l откат всех транзакций, не подтвержденных к моменту сбоя системы, с протоколированием в журнале транзакций;

l поскольку отмена транзакций изменяет структуру ФС на томе, NTFS должна протоколировать операцию отмены в журнале транзакций;

l сброс на диск изменений кэша;

l запись пустой области рестарта

Потом NTFS начинает проход отмены (undo pass), откатывая все транзакции, не подтвержденные к моменту сбоя системы. В таблице транзакций NTFS для каждой незавершенной транзакции хранится LSN записи модификации, которая была помещена в журнал последней. Каждая запись модификации содержит информацию двух видов: как повторить подоперацию и как отменить ее.

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

 

 

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