Пример 11.2. Структура инода файловой системы ext2fs 1 страница

/* * Структура данных инода second extended file system, считанная в память
*/
i- struct ext2_inode_info { _u32 i_data[15]; _ u32 i_flags; _u32 i^faddr; _ u8 i_frag_no; _ u8 i_f rag_size; _ u!6 i_osync; _ u32 i_file_acl; _ u32 i_dir_acl; _ u32 i_dtime;
_ u32 not_used_l; /* FIX: не используется/зарезервировано для 2.2 */ _ u32 i_block_group; _ u32 i_next_alioc_block;
u32 i next alloc goal; _ u32 i_prealloc_block;
u32 i prealloc count; __ u32 i_high_size;
int i_new _inode: 1; /* Этот инод только что вьделен */

Структура, описывающая физическое размещение файла на диске, недоступна пользовательским программам. Собственно, формат этой структуры может быть не очень элегантен. Например, в файловой системе Veritas это список экстентов, похожий на HPFS; в файловых системах s5, Xenix и FFS это массив из 13 чисел, задающих номера физических блоков файла. Если файл в s5 содержит более десяти блоков (т. е. его длина больше 5 Кбайт), то предпоследние три указателя обозначают не блоки данных, а так называемые косвенные блоки (indirection blocks), в которых хранятся указатели на следующие блоки данных и, возможно, на следующие косвенные блоки.
Наиболее интересная особенность ФС семейства Unix состоит не в этом. Внимательный читатель, возможно, заметил, что инод не содержит имени файла. С другой стороны, он содержит счетчик связей (link) — ссылок на этот файл из каталогов. Таким образом, на один и тот же инод можно ссылаться из различных каталогов или из одного каталога под разными именами (рис. 11.14). Иными словами, один и тот же файл в этих ФС может иметь несколько различных имен. Именно это и имелось в виду, когда го верилось, что структура каталогов в ОС UNIX не обязана быть деревом.
Это свойство предоставляет неоценимые возможности для организации не рархии каталогов, но имеет и некоторые оборотные стороны.

1. 1. Создание нескольких связей для каталога потенциально опасно— оно может привести к возникновению кольца, в котором каталог является своим собственным подкаталогом. Отслеживать такую ситуацию сложно поэтому разработчики ОС UNIX запретили создавать дополнительные имена для каталогов.
2. 2. Удаление файла превращается в проблему: чтобы удалить файл, нужно проследить все его связи. Поэтому UNIX не имеет средств для удатсния файла, а обладает только системным вызовом unlink — удалить связь. Когда у файла не остается связей, он действительно удаляется. Этот подход вполне разумен, но также имеет неожиданную оборотную сторону: поскольку теперь стирание файла — это операция не над файлом, а над каталогом, то для удаления файла не нужно иметь никаких прав доступа к нему. Достаточно иметь право записи в каталог.
   На практике, механизм защиты от стирания отдельных файлов предусмотрен — при установке в атрибутах каталога так называемого sticky bit ("липкий бит"), система запрещает стирать файлы, для которых вы не имеете права записи, но и этот механизм не лишен недостатков.
3. 3. Такие связи (называемые еще жесткими (hard) связями), как легко понять, могут создаваться только в пределах одной файловой системы, поскольку каждая ФС имеет собственную таблицу инодов, и соответственно собственную их нумерацию.

Рис. 11.14. Жесткие связи в Unix

Последнее обстоятельство резко уменьшает полезность жестких связей для организации иерархии каталогов. Эта проблема была осознана еще в 70-е годы, и программисты из группы BSD придумали интересное новое понятие - символическую связь (symbolic link) или symlink.
Символическая связь представляет собой специальный файл. Вместо блоков данных инод такого файла содержит текстовую строку — имя того файла, с которым создана связь (рис. 11.15). Это может быть файл из другой файловой системы, в том числе и из такой, которая сама по себе не поддерживает ни жестких, ни символических связей, например, FAT, HPFS или файловый сервер Novell Netware. Такого файла может и вообще не существовать, например, потому, что его уже удалили, или потому, что файловая система, в которой он находится, не смонтирована, или просто потому, что имя было задано неправильно. Тогда попытки открыть символическую связь будут завершаться неудачей с кодом ошибки "файла не существует".

Рис. 11.15. Символическая связь

Единственным недостатком символических связей является их относительно низкая "дуракоустойчивость" (fool-tolerance): глупый пользователь может не распознать ситуации, когда символическая связь указывает в никуда. Зато они обеспечивают полную свободу в размещении и именовании файлов.

Пример из жизни
На двух Unix-системах с именами orasrv и Indy установлен один и тот же программный продукт: редакторная система GNU Emacs. Бинарные загрузочные модули для этих систем различаются, но большая часть Emacs — это файлы на языке Emacs Lisp, которые с одинаковым успехом могут использоваться обеими системами. Поэтому у администратора системы возникает желание использовать одну копию lisp-файлов. При этом Emacs установлена таким обра зом, что она ищет все свои lisp-файлы в каталоге /usr/local/lib/emacs/19.27/lisp Изменение этого каталога потребовало бы частичной переустановки продукта Но его не надо менять! Мы просто подмонтируем на машине orasrv каталог / машины Indy как /fs/lndy и исполняем следующие команды примера 11.3.

Пример 11.3. Перенос каталога без изменения его путевого имени

cd /usr/local/lib/emacs/19.27 # перейти в заданный каталог rm -Rf lisp
# стереть каталог lisp со всем содержимым
In -s /fs/Indy/usr/local/lib/emacs/19.27/lisp lisp
# создать символическую связь с именем lisp с соответствующим
# каталогом на машине Indy

Вся операция вместе с ее планированием занимает около двух минут. Освобождается около 9 Мбайт дискового пространства. Emacs ничего не замечает, и работает без всяких проблем.
Через неделю у администратора возникает идея, что для удобства администрирования неплохо было бы монтировать с orasrv не всю файловую систему Indy, а только ее каталог /home. За чем дело стало: переносим на Indy каталог lisp в каталог /home/emacs/19.27/lisp; создаем в старом каталоге символическую связь с новой; редактируем файл /etc/mnttab на-машине orasrv так, чтобы с Indy монтировался только /home; меняем символическую связь каталога lisp на машине orasrv. Заставляем orasrv подмонтировать диски в соответствии с новым /etc/mnttab. Готово.
Операция занимает чуть больше двух минут, потому что нужно переносить 9 Мбайт из одной файловой системы в другую. Emacs опять ничего не замечает и снова работает без всяких проблем. Администратор счастлив. Все довольны. Сравните это описание с впечатлениями пользователя, который пытается переместить с одного ДОС-вского драйва на другой типичную программу для Win32, которая при установке записывает во многие места своей конфигурации и системного реестра полное имя каталога, в который ее ставили...

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

Жесткие связи в VMS и Windows NT/2000/XP
Например, в файловой системе VAX/VMS данные о размещении файлов на диске хранятся в специальном индексном (index) файле; каталоги же хранят только индексы записей в этом файле. Основное отличие этой структуры от принятой в Unix состоит в том, что вместо статической таблицы или набора таблиц используется динамическая таблица, пространство для которой выделяется тем же методом, что и для пользовательских файлов. Этот же подход реализован в файловой системе NTFS, используемой в Windows NT/2000/XP, но в ней индексный файл называется MFT (Main File Table — главная таблица файлов). Более подробное описание структуры NTFS приводится в статье [www.digit-life.com NTFS].
VAX/VMS и Windows NT позволяют создавать дополнительные имена для файлов, хотя в VMS утилиты восстановления ФС выдают предупреждение, обнаружив такое дополнительное имя. Все имена файла в этих ФС обязаны находиться в одной файловой системе. Кроме того, операция удаления файла в VMS ведет себя не так, как в Unix: применение операции удаления к любому из имен приводит к удалению самого файла, даже если существовали и другие имена.

Устойчивость ФС к сбоям

Свойство устойчивости к сбоям питания (power-fault tolerance) является одной из важных характеристик файловой системы. Строго говоря, имеется в виду устойчивость не только к сбоям питания, но и к любой ситуации, при которой работа с ФС прекращается без выполнения операции размонтирования. Поэтому правильнее было бы говорить об устойчивости к любым сбоям системы, а не только питания.
С другой стороны, если говорить просто об "устойчивости к сбоям", возникает неприятная двусмысленность. Под устойчивостью к сбоям можно понимать устойчивость к сбоям всей системы, например, к тем же сбоям питания, а можно понимать устойчивость к дефектам физического носителя, которые могут привести к потере части данных на диске. Вторая проблема обычно решается с помощью механизма горячей замены (логической переадресации) сбойных блоков, который обсуждается к разд. Устойчивость ФС к сбоям диска, а сейчас мы будем говорить только о первой проблеме, называя ее просто "устойчивостью" для краткости.

Устойчивость к сбоям питания

На самом деле, неожиданное прекращение работы с ФС может произойти не только при сбое питания, но и в следующих ситуациях:

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

На практике часто сложно провести границы между тремя последними типами сбоев. В качестве примера можно привести проблему, описанную в разд. Обмен данными с пользовательским процессом. В системах класса ДОС последняя причина возникает очень часто, поэтому в таких системах можно использовать только устойчивые сбоям ФС.
В системах класса ОС "спонтанные" зависания происходят намного реже Система, зависающая по непонятным или неустранимым причинам раз в несколько дней, считается малопригодной для серьезного использования а делающая это раз в месяц — подозрительно ненадежной. Поэтому в таких системах можно позволить себе роскошь использовать неустойчивые к сбоям ФС. Тем более что такие системы, как правило, обладают более высокой производительностью, чем устойчивые ФС.
К тому же перед выключением системы, интегрированной в сеть, необходимо уведомить всех клиентов и все серверы о разъединении. Только чисто клиентская машина может быть выключена из сети без проблем. Поэтому на сетевых серверах в любом случае необходима процедура закрытия системы (shutdown). Так почему бы не возложить на эту процедуру еще и функцию размонтирования ФС?
В системах же реального времени, которые по роду работы могут часто и неожиданно перезапускаться, например, при отладке драйверов или программ, осуществляющих доступ к аппаратуре, стараются использовать устойчивые к сбоям ФС.
Хотя первая из перечисленных выше причин — извлечение носителя из дисковода — не является "сбоем" даже в самом широком смысле этого слова, с точки зрения ФС она мало чем отличается от сбоя. Поэтому на удаляемых носителях, таких, как дискеты, можно использовать только устойчивые ФС.
Интересный альтернативный подход используется в компьютерах Macintosh и некоторых рабочих станциях. У этих машин дисковод не имеет кнопки для извлечения дискеты. Выталкивание дискеты осуществляется программно, подачей соответствующей команды дисководу. Перед подачей такой команды ОС может выполнить нормальное размонтирование ФС на удаляемом диске.
В узком смысле слова "устойчивость" означает лишь то, что ФС после аварийной перезагрузки не обязательно нуждается в восстановлении. Такие ФС обеспечивают целостность собственных структур данных в случае сбоя, но, вообще говоря, не гарантируют целостности пользовательских данных в файлах.
Нужно отметить, что даже если ФС считается в этом смысле устойчивой, некоторые сбои для нее могут быть опасны. Например, если запустить команду DISKOPT на "устойчивой" файловой системе FAT и в подходящий момент нажать кнопку RESET, то значительная часть данных на диске может быть навсегда потеряна.
С другой стороны, можно говорить об устойчивости в том смысле, что в ФС после сбоя гарантирована целостность пользовательских данных. Достаточно простого анализа для того чтобы убедиться, что такую гарантию нельзя обеспечить на уровне ФС; обеспечение подобной целостности накладывает серьезные ограничения и на программы, работающие с данными, а иногда оказывается просто невозможным.
Характерный и очень простой пример: архиватор InfoZip работает над созданием архива. Программа сформировала заголовок файла, упаковала и записала на диск около 50% данных, и в этот момент произошел сбой. В zip-архивах каталог находится в конце архивного файла и записывается туда после завершения упаковки всех данных. Обрезанный в случайном месте zip-файл не содержит каталога и поэтому, безусловно, является безнадежно испорченным. Поэтому при серьезном обсуждении проблемы устойчивости к сбоям говорят не о гарантии целостности пользовательских данных, а об уменьшении вероятности их порчи.
Поддержание целостности структур ФС обычно гораздо важнее, чем целостность недописанных в момент сбоя пользовательских данных. Дело в том, что если при сбое оказывается испорчен создававшийся файл, это достаточно неприятно; если же окажется испорчена файловая система, в худшем случае это может привести к потере всех данных на диске, т. е. к катастрофе. Поэтому обычно обеспечению целостности ФС при сбоях уделяется гораздо больше внимания.
Упоминавшаяся выше "врожденная" устойчивость к сбоям файловой системы FAT объясняется тем, что в этой ФС удаление блока из списка свободных и выделение его файлу производится одним действием — модификацией элемента FAT (рис. 11.16). Поэтому если во время этой процедуры произойдет сбой или дискета будет вынута из дисковода, то ничего страшного не случится: просто получится файл, которому выделено на один блок больше, чем его длина, записанная в каталоге. При стирании этого файла все его блоки будут помечены как свободные, поэтому вреда практически нет.

Рис. 11.16. Модификация FAT

Нужно отметить, что при активном использовании отложенной записи FAT и родственные ФС теряют это преимущество. Отложенная запись FAT является единственным способом добиться хоть сколько-нибудь приемлемой производительности от ФС с 32-битовым FAT. Поэтому, хотя Novell NetWare и использует ФС, основанную на 32-битной FAT, после аварийной перезагрузки эта система вынуждена запускать программу аварийною становления дисковых томов. Аналогичным образом ведет себя и FAT3? Если же система хранит в одном месте список или карту свободных блоков, а в другом месте списки блоков, выделенных каждому файлу (рис. 11.17) как это делают HPFS или ФС систем семейства Unix, то при прерывании операции выделения места в неподходящий момент могут либо теряться блоки (если мы сначала удаляем блок из списка свободных— рис. 11.18) либо получаться блоки, которые одновременно считаются и свободными, и занятыми (если мы сначала выделяем блок файлу).
Первая ситуация достаточно неприятна, вторая же просто недопустима: первый же файл, созданный после перевызова системы, будет "перекрещиваться" с испорченным (рис. 11.19). Поэтому все ОС, использующие файловые системы такого типа (системы семейства Unix, OS/2, Windows NT и т. д.), после аварийной перезагрузки первым делом проверяют своп ФС соответствующей программой восстановления.

Рис. 11.17. Модификация структур данных сложной ФС

Рис. 11.18. Потерянный блок

Рис. 11.19. Пересекающиеся файлы

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

Восстановление ФС после сбоя

Чаще всего суперблок неустойчивых ФС содержит флаг flirty ("грязный"), сигнализирующий о том, что ФС, возможно, нуждается в восстановлении. Этот флаг сбрасывается при нормальном размонтировании ФС и устанавливается при ее монтировании или при первой модификации после монтирования. Таким образом, если ОС погибла, не успев размонтировать свои дисковые тома, после перезагрузки на этих томах dirty-флаг будет установлен, что и станет сигналом необходимости починки.
Восстановление состоит в том, что система проверяет пространство, выделенное всем файлам. При этом должны выполняться следующие требования.

1. 1. Каждая запись в каталоге должна иметь правильный формат и содержать осмысленные данные. Например, если запись помечена как свободная, она не должна ссылаться на данные, помеченные как принадлежащие файлу, или на и под. Не во всех ФС можно обнаружить ошибки такого типа.
2. 2. Каждый блок или кластер диска должен принадлежать не более, чем одному файлу. Блоки, принадлежащие одновременно двум или более файлам, являются очень серьезной ошибкой. На практике это означав что данные во всех этих файлах (в лучшем случае — во всех, кроме того запись в который была последней) безнадежно испорчены. Чаще всего программа восстановления в этой ситуации требует вмешательства попь зователя, с тем чтобы решить, какие из файлов следует удалить или обре зать по месту пересечения. Иногда для каждого из файлов создается ко пия "общего" блока, но и в этом случае пользователю все равно нужно определить, какие из файлов испорчены.

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

1. 3. Каждому файлу должно быть выделено пространство, соответствующее его длине. Если файлу выделено больше блоков, чем требуется, лишние блоки помечаются как свободные. Если меньше, файл укорачивается. Возможно, в укороченных файлах часть данных оказывается потеряна.
2. 4. Все блоки, не принадлежащие файлам, должны быть помечены, как свободные. Соответствующий тип ошибок — потерянные блоки — наиболее частый результат системных сбоев как в файловой системе FAT, так и в более сложных файловых системах. Сами по себе ошибки этого типа относительно безобидны.

Обычно программа восстановления не помечает потерянные блоки как свободные, а выделяет из них непрерывные цепочки и создает из этих цепочек файлы. Например, в OS/2 программа восстановления пытается найти в потерянных блоках файловые записи, а потом создает ссылки на найденные таким образом файлы в каталоге \FOUND.XXX. В DOS эти файлы помещаются в корневой каталог ФС под именами FILEXXXX.CHK (вместо ХХХХ подставляется номер). Предполагается, что пользователь просматривает все такие файлы и определяет, не содержит ли какой-то из них ценной информации, например, конца насильственно укороченного файла.
В системах семейства Unix существует несколько специфических ошибок, связанных с инодами.

• Инод, внутренний счетчик ссылок которого не соответствует реальному количеству ссылок из каталогов. Эта проблема может возникать при системном сбое в момент удаления существовавшей связи или создания повой. Она решается коррекцией внутреннего счетчика инода. После этого можно обнаружить следующие две ошибки.
• Инод, не имеющий ни одной ссылки, но и не помеченный как свободный — сирота (orphan) (рис. 11.20). Ссылка на такой и под создается в каталоге lost+foiind;
• Инод с непулевым количеством ссылок из каталогов, но помеченный как свободный. Чаще всего это свидетельствует о порче самого каталога. Обычно ссылки на такой инод удаляются.

Рис. 11.20. Инод-сирота

Ручное восстановление файловой системы
В некоторых особенно тяжелых случаях программа восстановления оказывается не в состоянии справиться с происшедшей аварией и администратору системы приходится браться за дисковый редактор.
В процессе эксплуатации системы SCO Open Desktop 4.0 у автора неоднократно возникала необходимость выполнять холодную перезагрузку без нормального размонтирования файловых систем. Одна из таких перезагрузок привела к катастрофе.
Дисковая подсистема машины состояла из кэширующего контроллера дискового массива. Контроллер активно использовал отложенную запись, что, по-видимому, и послужило причиной катастрофы. Во время планового резервного копирования драйвер лентопротяжки "впал в ступор" и заблокировал процесс копирования (механизм возникновения этой аварии подробнее обсуждался в разд. Обмен данными с пользовательским процессом). Из-за наличия зависшего процесса оказалось невозможно размонтировать файловую систему, и машина была перезагружена нажатием кнопки RESET без выполнения нормального закрытия, в том числе и без выполнения операции закрытия драйвера дискового массива, которая должна была сбросить на диски содержимое буферов контроллера.
После перезагрузки система автоматически запустила программу восстановления файловой системы fsck (File System ChecK), которая выдала радостное сообщение: DUP in inode 2. Для незнакомых с системными утилитами Unix н обходимо сказать, что DUP означает ошибку перекрещивания файлов, а инп~ 2— это инод корневого каталога ФС. Таким образом, корневая директория дискового тома объемом около 2 Гбайт оказалась испорчена. При этом пода ляющее большинство каталогов и файлов были не затронуты катаклизмом оказались недоступны. Программа восстановления не могла перенести ссылк на соответствующие иноды в каталог lost+found, так как ссылка на него такж идет из корневого каталога.
Ситуация представлялась безвыходной. Катастрофа усугублялась тем, что произошла она во время резервного копирования, а последняя "хорошая" копия была сделана неделю назад. Большую часть пользовательских данных можно было бы восстановить, но среди потерянных файлов оказался журнальный файл сервера СУБД ORACLE (сама база данных находилась в другом разделе диска). Пришлось заняться восстановлением ФС с использованием дискового редактора, мотивируя это тем, что "терять все равно уже нечего" Собственно, в восстановлении ФС участвовало два человека — автор и штатный администратор системы. Автор ни в коем случае не хочет создать у читателя впечатление, что план восстановления был разработан лично им — это был плод совместных усилий, проб и ошибок.
Редактирование системных данных "сложных" ФС с использованием простого шестнадцатеричного дискового редактора является крайне неблагодарным занятием. Есть основания утверждать, что это вообще невозможно. Во всяком случае, автору не доводилось слышать об успехе такого предприятия. К счастью, системы семейства Unix предоставляют для редактирования ФС специальную программу fsdb (File System DeBugger— отладчик файловой системы). Пользовательским интерфейсом эта программа напоминает программу DEBUG.COM, поставляемую с MS DOS; главным ее преимуществом является то, что она "знакома" с основными понятиями файловой системы. Так, например, fsdb позволяет просмотреть содержимое 10-го логического блока файла с инодом 23 456, выделить физический блок 567 345 файлу с инодом 2 или пометить инод 1245 как свободный.
Первая попытка восстановления состояла в том, что мы удалили тот инод, с которым перекрещивался корневой каталог, смонтировали том командой "безусловного" монтирования (которая позволяла монтировать поврежденные тома), создали командой mkdir каталог lost+found и вновь запустили fsck. Попытка завершилась крахом. Беда была в том, что, как оказалось, корневой каталог пересекался также и со списком свободных блоков, т. е. создание каталога, а потом его расширение командой f sck снова приводило к порче корневого каталога и задача сводилась к предыдущей.
Таким образом, нам необходимо было либо исправить вручную список свободных блоков, либо найти способ создать директорию lost+found без обращений к этому списку. Дополнительная сложность состояла в том, что с каталогом lost+found не связано фиксированного инода, а определить инод старого lost+found не представлялось возможным.
Мы решили не связываться с восстановлением списка свободных блоков. Вместо этого мы просмотрели листинг последней "правильной" резервной копии, нашли там ненужный пустой каталог и присоединили его к корневому под названием lost+found. После этого нам оставалось лишь уповать на то, что вновь создаваемые f sck-ссылки на файлы не приведут к необходимости удлинить наш lost+found. К счастью, этого не произошло: все потомки корневого каталога благополучно получили имена в lost+found. По существу, ФС пришла в пригодное для чтения состояние, оставалось лишь правильно определить имена найденных каталогов. Это также оказалось относительно несложной задачей: большая часть каталогов на томе состояла из домашних каталогов пользователей и их имена можно было восстановить на основании того, кому эти каталоги принадлежали. Для остальных каталогов имя достаточно легко определялось после сопоставления их содержимого с листингом резервной копии.

Во многих современных ОС реализованы устойчивые к сбоям файловые системы: jfs в AIX и OS/2 v4.5, Veritas в UnixWare, NTFS в Windows NT/2000/XP. Практически все такие ФС основаны на механизме, который по-английски называется intention logging (регистрация намерений).

Файловые системы с регистрацией намерений

Термин, вынесенный в заголовок этого подраздела, является дословной калькой (возможно, не очень удачной) англоязычного термина intention logging. В русском языке, к сожалению, еще нет общепринятого термина для этого понятия.
Идея журналов регистрации намерений пришла из систем управления базами данных. В СУБД часто возникает задача внесения согласованных изменений в несколько разных структур данных. Например, банковская система переводит миллион долларов с одного счета на другой. СУБД вычитает 1 000 000 из суммы на первом счету, затем пытается добавить ту же величину ко второму счету и в этот момент происходит сбой.
Для СУБД этот пример выглядит очень тривиально, но мы выбрали его потому, что он похож на ситуацию в файловой системе: в каком бы порядке Ни производились действия по переносу объекта из одной структуры в другую, сбой в неудачный момент приводит к крайне неприятной ситуации. В СУБД эта проблема была осознана как острая очень давно — ведь миллион долларов всегда был намного дороже одного сектора на диске.
Удовлетворительное решение проблемы заключается в следующем.

• Во-первых, все согласованные изменения в СУБД организуются в блоки, называемые транзакциями (transaction). Каждая транзакция осуществляется как неделимая (атомарная) операция, во время которой никакие другие операции над изменяемыми данными не разрешены.
• Во-вторых, каждая транзакция осуществляется в три этапа (рис. 11.21)
• Система записывает в специальный журнальный файл, что же она с бирается делать.
• Если запись в журнал была успешной, система выполняет транзакцию.
• Если транзакция завершилась нормально, система помечает в журнале, что намерение было успешно реализовано.

Рис. 11.21. Выполнение транзакции с регистрацией намерений

Журнал часто называют журналом регистрации намерений (intention log), что очень хорошо отражает суть дела, потому что в этот журнал записываются именно намерения (intentions).
При использовании отложенной записи транзакция считается полностью завершенной, только когда последний блок измененных данных будет физически записан на диск. При этом в системе обычно будет одновременно существовать несколько незавершенных транзакций (рис. II.22). Легко понять, что при операциях с самим журналом отложенную запись вообше нельзя использовать.