Московский физико-технический институт
Опубликован: 12.12.2007 | Доступ: свободный | Студентов: 5489 / 1826 | Оценка: 4.34 / 4.14 | Длительность: 13:57:00
ISBN: 978-5-94774-827-7
Лекция 12:

Реализация файловой системы. Файловая система NTFS

< Лекция 11 || Лекция 12: 1234 || Лекция 13 >

Восстанавливаемая файловая система NTFS

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

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

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

В журнал заносятся не все изменения, а лишь изменения метаданных (MFT-записей и др.). Изменения в данных пользователя в протокол не заносятся. Если протоколировать изменения пользовательских данных, то этим будет нанесен серьезный ущерб производительности системы, поскольку кэширование потеряет смысл. Затраты на журналирование могут быть частично скомпенсированы за счет увеличения интервала между сбросами кэша на диск.

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

  1. Вначале в кэшируемый файл журнала заносится запись о предполагаемой транзакции.
  2. Затем делается собственно транзакция, то есть модифицируется файловая система (также в кэше).
  3. После этого запись в файле журнала сбрасывается на диск.
  4. Наконец, сбросив на диск файл журнала, диспетчер кэша записывает на диск изменения в файловой системе (результаты операции над метаданными).

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

Проверка целостности файловой системы при помощи утилит

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

Решение проблемы плохих блоков

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

Фиксация изменений в файловой системе

Для решения ряда проблем необходимо уметь фиксировать изменения файловой системы по истечении некоторого промежутка времени. Например, обнаружение нарушения целостности файлов, содержащих компоненты самой операционной системы, является способом защиты от внешнего навязывания и одним из средств повышения общей безопасности системы (см. "Отдельные аспекты безопасности Windows" ). Другим примером может быть актуализация сведений о файлах в диалогах и окнах программ, работающих с файлами.

Для решения подобных задач ОС Windows располагает самыми широкими возможностями. Для знакомства с данной техникой рекомендуется изучить работу программных примеров из MSDN (см. раздел MSDN Using File I/O), или особенности применения функции FindFirstChangeNotification.

Поддержка нескольких файловых систем

Подобно многим современным операционным системам ОС Windows поддерживает несколько файловых систем (CDFS, UDF, FAT, NTFS, удаленные FS). Эта возможность заложена в архитектуре системы ввода-вывода. Список зарегистрированных файловых систем можно "увидеть" с помощью утилиты WinObj.

Код, реализующий функциональность каждой файловой подсистемы ОС, входит в состав соответствующего драйвера файловой системы. Запрос прикладной программы на чтение (запись) из файла передается диспетчеру ввода-вывода, который пытается обслужить этот запрос с помощью единого интегрированного кэша (см. рис. 12.8).

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

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

Заключение

Настоящая лекция описывает отдельные аспекты реализации файловой системы NTFS. Главная функция файловой системы - связь символьного имени с блоками диска - реализована за счет поддержки списка блоков в записи о файле в главной файловой таблице MFT. Для быстрого поиска файла по имени каталог может быть организован в виде B+ дерева. Проблемы монтирования дисков и связывания файлов решаются с помощью точек повторного анализа. Производительность файловой системы обеспечивается менеджером кэша, а также путем оптимального размещения информации на диске. Для восстановления системы после отказа питания ведется журнал файловых операций с метаданными. Поддержка нескольких файловых систем в ОС Windows обеспечивается оригинальной структурой подсистемы ввода-вывода, в рамках которой для каждой файловой системы имеется соответствующий драйвер.

< Лекция 11 || Лекция 12: 1234 || Лекция 13 >
Ирина Оленина
Ирина Оленина
Николай Сергеев
Николай Сергеев

Здравствуйте! Интересует следующий момент. Как осуществляется контроль доступа по тому или иному адресу с точки зрения обработки процессом кода процесса. Насколько я понял, есть два способа: задание через атрибуты сегмента (чтение, запись, исполнение), либо через атрибуты PDE/PTE (чтение, запись). Но как следует из многочисленных источников, эти механизмы в ОС Windows почти не задействованы. Там ключевую роль играет менеджер памяти, задающий регионы, назначающий им атрибуты (PAGE_READWRITE, PAGE_READONLY, PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_NOACCESS, PAGE_GUARD: их гораздо больше, чем можно было бы задать для сегмента памяти) и контролирующий доступ к этим регионам. Непонятно, на каком этапе может включаться в работу этот менеджер памяти? Поскольку процессор может встретить инструкцию: записать такие данные по такому адресу (даже, если этот адрес относится к региону, выделенному менеджером памяти с атрибутом, например, PAGE_READONLY) и ничего не мешает ему это выполнить. Таким образом, менеджер памяти остается в стороне не участвует в процессе...