Файловые системы с регистрацией намерений
Термин, вынесенный в заголовок этого подраздела, является дословной калькой (возможно, не очень удачной) англоязычного термина intention logging. В русском языке, к сожалению, еще нет общепринятого термина для этого понятия.
Идея журналов регистрации намерений пришла из систем управления базами данных. В СУБД часто возникает задача внесения согласованных изменений в несколько разных структур данных. Например, банковская система переводит миллион долларов с одного счета на другой. СУБД вычитает 1 000 000 из суммы на первом счету, затем пытается добавить ту же величину ко второму счету и в этот момент происходит сбой.
Для СУБД этот пример выглядит очень тривиально, но мы выбрали его потому, что он похож на ситуацию в файловой системе: в каком бы порядке Ни производились действия по переносу объекта из одной структуры в другую, сбой в неудачный момент приводит к крайне неприятной ситуации. В СУБД эта проблема была осознана как острая очень давно – ведь миллион долларов всегда был намного дороже одного сектора на диске.
Удовлетворительное решение проблемы заключается в следующем.
- Во-первых, все согласованные изменения в СУБД организуются в блоки, называемые транзакциями (transaction). Каждая транзакция осуществляется как неделимая (атомарная) операция, во время которой никакие другие операции над изменяемыми данными не разрешены.
- Во-вторых, каждая транзакция осуществляется в три этапа (рис. 11.21):
- Система записывает в специальный журнальный файл, что же она собирается делать.
- Если запись в журнал была успешной, система выполняет транзакцию.
- Если транзакция завершилась нормально, система помечает в журнале, что намерение было успешно реализовано.
Рис. 11.21. Выполнение транзакции с регистрацией намерений
Журнал часто называют журналом регистрации намерений (intention log), что очень хорошо отражает суть дела, потому что в этот журнал записываются именно намерения (intentions).
При использовании отложенной записи транзакция считается полностью завершенной, только когда последний блок измененных данных будет физически записан на диск. При этом в системе обычно будет одновременно существовать несколько незавершенных транзакций (рис. 11.22). Легко понять, что при операциях с самим журналом отложенную запись вообще нельзя использовать.
Рис. 11.22. Очередь исполняющихся транзакций