5.4.1 Восстановление фс после сбоя.

Чаще всего неустойчивые ФС содержат специальный флаг (бит), сигнализирующий о том, что ФС возможно нуждается в починке. Этот флаг сбрасывается при нормальном размонтировании ФС и устанавливается при ее монтировании или при первой модификации после монтирования. Починка состоит в том, что система отслеживает пространство, выделенное всем файлам, при этом должны выполняться следующие требования. Каждая запись в каталоге должна иметь правильный формат и содержать осмысленные данные, например если запись помечена как свободная, она не должна ссылаться на данные, помеченные как принадлежащие файлу. Каждый блок или кластер должен принадлежать не более чем одному файлу, блоки, принадлежащие одновременно двум или более файлам являются очень серьезной ошибкой. Чаще всего программа починки в этой ситуации требует вмешательства пользователя с тем, чтобы решить какой из файлов следует обрезать по месту пересечения. Иногда для каждого из файла создается копия из общих блоков. Возникновение таких ошибок обычно сигнализирует либо об ошибке в драйвере ФС, либо об аппаратных сбоях на диске, либо о том что структуры ФС были модифицированы в обход драйвера ФС. 3 – Каждому файлу должно быть выделено пространство, соответствующее его длинне. Если файлу выделено больше блоков, чем заявлено, лишние блоки помечаются как свободные. 4 – все блоки, не принадлежащие файлам, должны быть помечены как свободные, соответствующий тип ошибок, потерянные блоки (кластеры), сами по себе ошибки этого типа относительно безобидны. Обычно программа починки не помечает потерянные блоки как свободные, а выделяет из них непрерывные цепочки и создает из них файлы. Предполагается, что пользователь просматривает такие файлы, и определяет, не содержит ли хоть какой то из них ценной информации.

5.4.2 Фс с трассировкой транзакций.

Во многих современных ОС реализованы ФС устойчивые к сбоям. Большинство таких ФС основаны на механизме, который называется трассировка транзакций (регистрация намерений). Идея журналов трассировки транзакций пришла из СУБД (а туда из банковской сферы). В ФС часто возникает задача внесение согласованных изменений в несколько разных структур данных. При этом удовлетворительное решение проблемы сохранения целостности данных заключается в следующем: 1 – все согласованные изменения в ФС организуются в блоки, называемые транзакциями, каждая транзакция осуществляется как неделимая (атомарная) операция, во время которой никакие другие операции над этими изменяемыми данными не разрешены; 2 – каждая транзакция осуществляется в 3 этапа:

- система записывает в специальный журнальный файл информацию о планировании операции над данными;

- если запись в журнал была успешной, система выполняет операцию, если операция завершилась нормально, система помечает в журнале, что транзакция была успешно реализована;

- если произошел сбой системы, после перезагрузки запускается программа починки ФС, эта программа просматривает журнал, если она видит там запись, которая отмечает начатую, но не выполненную транзакцию, то сбой произошел во время этой транзакции (необходимо выполнить заного транзакцию);

- если найдена испорченная запись, то сбой произошел во время записи в журнал (удалить запись);

- если все записи помечены как успешно выполненные операции, то сбой произошел между транзакциями и ничего чинить не надо;

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