Ростелеком ТВ 

Что такое журналируемые файловые системы? Журналируемая файловая система. Будущее журналируемых файловых систем

Изначально стандартной файловой системой для Linux была Ext2fs. Ext2 основана на структуре i-node. I-node содержит информацию о файле и указатели на блоки данных, в которых расположен файл. Для повышения быстродействия операций ввода/вывода данные временно располагаются в оперативной памяти. Проблема возникает, если сбой происходит до того, как данные из кэша перепишутся на диск. Это вызывает несоответствие в файловой системе. Например, возникает ссылка на файл, еще не созданный на диске, или файлы были уже удалены, но их i-nodes и блоки данных остались на диске. Fsck (File system check – проверка файловой системы) – стандартная программа для устранения несоответствий. Единственный способ это сделать – просканировать весь диск, и проверить все зависимости между i-nodes, блоками данных и содержанием директорий. С увеличением объемов дисков эта процедура стала занимать огромное количество времени – серьезная проблема для серверов, которые должны работать постоянно.

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

Журналируемая файловая система – это устойчивая к сбоям файловая система, в которой целостность данных гарантирована, потому что обновления в meta-данных файлов записываются в log на диске перед любыми изменениями в структуре файловой системы. В случае сбоя журналируемая файловая система гарантирует восстановление всех потерянных данных. Самый распространенный подход – это метод журналирования или логгирования meta-данных файлов. Его суть в том, что информация о любом изменении записывается в зарезервированную область файловой системы, и только после этого совершается само изменение.

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

Linux имеет три основные журналируемые FS – это ReiserFS от Namesys, XFS от SGI, и Ext3, разработанная Stephen Tweedie, участвовавшим в создании Ext2.

Самый простой инструмент для улучшенного по сравнению с традиционными Unix-системами быстродействия – это избежание использования связанных списков или bitmaps, которые содержат в себе проблему масштабируемости и неприменимы для новых дисков с огромной вместимостью. Все новые системы используют Balanced Trees (B-Trees), или их вариацию (B+Trees).

Дерево состоит из внутренних и листовых узлов. Каждый узел (node) – это дисковый блок. Каждому объекту (файлу, каталогу) назначается уникальный ключ, аналогичный номеру inode в других файловых системах. Внутренние узлы, главным образом, состоят из ключей и указателей на узлы-потомки. Узел, который начинает дерево, известен как корень; узлы, которые сидят на конце ветви дерева иногда называются листьями.

Время поиска в B+Trees пропорционально не количеству объектов (файлов в каталоге или числа блоков на диске), а логарифму этого числа. В сбалансированном дереве все ветви (пути от корня до «листа») имеют одинаковую (или примерно одинаковую) длину.

ReiserFS базируется на B+Tree в организации объектов файловой системы. ReiserFS предоставляет только журналирование meta-данных. В случае незапланированной перезагрузки данные в блоках, используемых во время сбоя, могут быть повреждены, так что ReiserFS не гарантирует того, что после сбоя данные останутся неповрежденными.

ReiserFS также имеет ряд особенностей, нацеленных специально для улучшения работы с маленькими файлами. Одна из специальных возможностей ReiserFS – это Tail Packing. Tail – это файл, размер которого меньше, чем логический блок, или какие-то части файлов, занимающие меньше, чем один блок. Для сохранения свободного места ReiserFS использует сжатие tail-файлов, и это позволяет примерно на 5 % увеличить свободное место по сравнению с Ext2. Для увеличения скорости, ReiserFS способен хранить содержимое файлов непосредственно внутри b*tree, а не в виде указателя на дисковый блок.

XFS была создана в начале 90-х (1992–1993) фирмой Silicon Grapgics (сейчас SGI) для мультимедийных компьютеров с ОС Irix. Файловая система была ориентирована на очень большие файлы и файловые системы. 1 мая 2001 года SGI выпустила первый релиз XFS для Linux.

Для увеличения масштабируемости файловой системы XFS обширно использует B+Trees. XFS допускает хранение журнала на другом блочном устройстве.

XFS имеет такую возможность, как delayed allocation (Отложенное размещение) – вместо того, что бы выделять блоки файлу в момент его записи в кэш, XFS просто резервирует блоки в файловой системе, размещая данные в специальных виртуальных зонах (virtual extents). Когда весь файл содержится в памяти, то он обычно может быть размещен в одном куске непрерывного дискового пространства. Тем самым предотвращается фрагментация файлов.

Максимальный размер файла – 9 млн. Тбайт

В ReiserFS неожиданная перезагрузка может иметь результатом попадание в изменяемый файл фрагмента из когда-то удаленного файла. Помимо очевидной потери данных, гипотетически это может иметь более серьезные последствия. В XFS имеется гарантия, что любые «недозаписанные» блоки заполнены нулями. Так как блоки с нулевыми байтами в системных файлах игнорируются, устраняется лазейка в безопасности.

Ext3 – надстройка над Ext2. С одной стороны, она позволяет вести лог операций для более быстрого восстановления. Но эта файловая система унаследовала некоторые ограничения от Ext2 (например, она базируется на блоках и использует полный перебор при поиске файлов и директорий), и поэтому ее нельзя назвать чистой журналируемой файловой системой.

Журнал располагаться в любой другой файловой системе. Возможно иметь несколько файловых систем Ext3 с совместным журналом.

Типы журналирования поддерживаемые Ext3, которые могут быть активированы из файла /etc/fstab:

  • data=journal (full data journaling mode) – все новые данные сначала пишутся в журнал и только после этого переносятся на свое постоянное место. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние. Самый медленный, но самый надежный.
  • data=ordered – записываются изменения только метаданных файловой системы, но логически metadata и data блоки группируются в единый модуль, называемый transaction. Перед записью новых метаданных на диск, связанные data блоки записываются первыми. Этот режим установлен по умолчанию. При добавлении данных в конец файла режим data=ordered гарантированно обеспечивает целостность (как при full data journaling mode). Однако, если данные в файл пишутся поверх существующих, то есть вероятность перемешивания «оригинальных» блоков с модифицированными. Это результат того, что data=ordered не отслеживает записи, при которых новый блок ложится поверх существующего и не вызывает модификации метаданных.
  • data=writeback (metadata only) – записываются только изменения метаданных файловой системы. Самый быстрый метод журналирования. Аналогичен используемому в XFS и ReiserFS.

Файловая система NTFS начала свое существование вместе с Windows NT 3.5 в 1993 году. Она умеет управлять дисками размером до нескольких сотен терабайт.

Каждый файл на томе NTFS представлен записью в специальном файле, называемом главной файловой таблицей (MFT – master file table). Первая запись этой таблицы описывает непосредственно главную файловую таблицу;

За ней следует зеркальная запись (mirror record) MFT. Если первая запись MFT разрушена, то NTFS читает вторую запись для отыскания зеркального файла MFT.

Третья запись MFT – файл регистрации (log file); содержит список шагов транзакции, используемых Log File System для восстановления файлов в случае сбоя. Семнадцатая и последующие записи главной файловой таблицы используются собственно файлами и каталогами.

Небольшие файлы и каталоги могут полностью содержаться внутри записи главной файловой таблицы. Большие каталоги организованы в B-tree, имея записи с указателями на внешние кластеры, содержащие элементы каталога, которые не могли быть записаны внутри структуры MFT.

Настоящее и будущее журналирования

Существует множество определений журналируемых файловых систем, однако давайте приведем формулировку, понятную каждому: журналируемая файловая система - это систем для тех, кому надоела программа проверки fsck во время загрузки. Также это система для тех, кому близка идея устойчивых к сбоям систем. Если некорректно отключить питание в обычной системе, где отсутствует журналирование, то ОС обнаруживает этот факт и запускает утилиту проверки целостности диска fsck при следующей загрузке. Эта утилита сканирует файловую систему и пытается устранить проблемы, не нанося вреда данным. Процесс проверки может занять довольно много времени. Иногда файловая система повреждается настолько сильно, что ОС загружается только в однопользовательском режиме и предлагает пользователю провести дальнейшее восстановление.

Скажи fsck

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

Итак, теперь вы знаете, кто нуждается в журналируемых файловых системах, однако почему таким системам не нужны проверки fsck ? Вкратце - потому, что в них ведется специальный журнал. Журнал - это файл, представляющий собой кольцевой буфер, в который заносятся все действия, связанные с изменением файловой системы. Периодически эти изменения применяются к файловой системе. В случае сбоя, журнал может быть использован в качестве отправной точки для восстановления несохраненных данных и для предотвращения повреждения метаданных.

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

Что такое метаданные?

Метаданными называются служебные структуры данных, необходимые для хранения основных данных. Такие операции, как создание и удаление файла и каталога, увеличение файла, усечение файла и.т.д., затрагивают метаданные.

Рисунок 1. Типичная журналируемая файловая система.

История журналируемых файловых систем Linux

IBM® первой разработала журналируемую файловую систему, которая называлась JFS (Journaled File System). Первая версия JFS была представлена в 1990 году, а современная версия поддерживается в Linux как JFS2, разработанная позже. В 1994 году компания Silicon Graphics представила высокопроизводительную файловую систему XFS для ОС IRIX. В 2001 году XFS была портирована для Linux. В 1998 году для систем Amiga была разработана файловая система Smart File System (SFS), которая впоследствии выпускалась под лицензией GNU Lesser General Public License (LGPL) и получила поддержку в Linux 2005 году. Наибольшее распространение получила файловая система ext3fs (от англ. third extended file system ), которая является расширением системы ext2 с добавлением журналирования. Поддержка ext3fs появилась в Linux в 2001 году. И наконец, получившая широкое распространение журналируемая файловая система ReiserFS открыла много новых путей и возможностей для развития. Однако развитие этой системы замедлилось в связи с юридическими проблемами ее автора.

Разновидности журналирования

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

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

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

Журналируемые файловые системы сегодня

На сегодняшний день активно используется несколько журналируемых файловых систем, каждая из которых имеет свои преимущества и недостатки. Ниже представлена четверка самых популярных журналируемых файловых систем.

JFS2

JFS2 (также известная как улучшенная журналируемая файловая система ) является первой журналируемой файловой системой и долгое время применялась в ОС IBM AIX®, прежде чем была перенесена в Linux. JFS2 - это 64-разрядная файловая система, которая, имея корни оригинальной JFS, была заметно усовершенствована в плане масштабируемости и поддержки многопроцессорных архитектур.

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

JFS2 также использует B+-деревья как для эффективного поиска по каталогам, так и для управления дескрипторами экстентов. JFS2 не имеет собственной политики переноса изменений на диск, - вместо этого она основывается на таймауте демона kupdate.

XFS

XFS - еще одна из ранних журналируемых файловых систем, первоначально разработанная Silicon Graphics в 1995 году для ОС IRIX. В 2001 году XFS была реализована в Linux, уже будучи на тот момент продуманной и надежной файловой системой.

XFS использует полноценную 64-разрядную адресацию и обеспечивает очень высокую производительность за счет применения B+-деревьев для размещения каталогов и файлов. XFS хранит данные в виде экстентов, поддерживая переменный размер экстентов (от 512 байт до 64 килобайт). Наряду с экстентами в XFS применяется отложенное размещение, при котором размещение блоков задерживается до тех пор, пока не наступит время их записи на диск. Такая особенность повышает вероятность заполнения подряд нескольких дисковых блоков, поскольку на момент записи будет известно их количество.

Другие интересные свойства XFS - это гарантированная скорость ввода/вывода, когда пользователям файловой системы выделяется резерв пропускной способности для операций ввода/вывода, и прямой ввод/вывод, при котором данные копируются напрямую между диском и буфером приложения (вместо того чтобы проходить несколько буферов). Журналирование в XFS ведется методом обратной записи.

Третья расширенная файловая система (ext3fs)

Третья расширенная файловая система (ext3fs) - наиболее популярная журналируемая файловая система, возникшая как эволюция известной файловой системы ext2. На самом деле она совместима с ext2, так как оперирует идентичными структурами, но с добавлением журнала. Более того, возможно смонтировать раздел ext3 как ext2 либо преобразовать ext2 в ext3, используя утилиту tune2fs .

В ext3fs поддерживаются все три стратегии журналирования (обратная запись, упорядочивание и режим данных), однако по умолчанию используется режим упорядочивания. Политику переноса данных журнала на диск можно настраивать, но изначально она такова, что перенос происходит либо по заполнении 1/4 журнала, либо по истечении одного из таймеров переноса.

Один из главных недостатков ext3fs происходит из того, что она изначально не задумывалась как именно журналируемая файловая система. Поскольку она основана на ext2fs, в ней отсутствуют многие прогрессивные нововведения, имеющиеся в других файловых системах (например, экстенты). Также она обычно показывает слабую производительность по сравнению с ReiserFs, JFS и XFS, однако меньше нагружает процессор и потребляет памяти, чем многие другие файловые системы.

ReiserFS

Что такое уплотнение хвостов?

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

Файловая система ReiserFS с самого начала создавалась как журналируемая. В 2001 году она была добавлена в главную ветку ядра 2.4 и стала первой журналируемой файловой системой, появившейся в Linux. Основной метод журналирования - упорядочивание. Поддерживается увеличение размера файловой системы "на лету". ReiserFS также поддерживает уплотнение хвостов для динамического уменьшения фрагментации, что позволяет ей обгонять по скорости ext3fs при работе с маленькими файлами.

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

Репутация ReiserFS была несколько раз подпорчена: последний раз - проблемами автора системы с законом (подробную информацию см. в разделе ).

Будущее журналируемых файловых систем

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

Reiser4

После успешного внедрения ReiserFS в ядро и применения во многих дистрибутивах Linux компания Namesys (которая стоит за ReiserFS) начала работу над новой журналируемой файловой системой, Reiser4, которая была создана полностью с нуля и включает в себя множество передовых возможностей.

Улучшенное журналирование в Reiser4 достигается за счет использования блуждающих записей и отложенного размещения блоков до момента переноса данных журнала (как это было сделано в XFS). В архитектуре Reiser4 предусматривалась гибкая поддержка плагинов (например, чтобы добавить функции сжатия или шифрования), но эта идея была отвергнута Linux-сообществом, которое считало, что место этим расширенным функциям - в подсистеме виртуальной файловой системы (VFS).

После вынесения обвинения владельцу Namesys и одновременно автору ReiserFS вся коммерческая деятельность вокруг Reiser4 была приостановлена.

Четвертая расширенная файловая система

Четвертая расширенная файловая система (ext4fs) - это дальнейшее развитие ext3fs. Ext4fs была задумана как замена ext3fs, имеющая с ней прямую и обратную совместимость, но включающая в себя множество улучшений (некоторые из которых нарушают эту совместимость). На практике можно монтировать раздел ext4 как ext3 и наоборот.

Во-первых, ext4fs - это 64-разрядная файловая система с поддержкой томов огромного размера (до 1 эксабайта). Она также может использовать экстенты, но в этом случае теряется совместимость с ext3fs. Аналогично XFS и Reiser4, в ext4fs размещение блоков на диске задерживается и происходит по необходимости (что уменьшает фрагментацию). Журнал также хранит контрольные суммы содержимого для большей надежности. Вместо B+- или B*-деревьев применяется специальная разновидность B-дерева, т.н. H-дерево , что позволяет поддиректориям иметь намного больший размер (в ext3 он ограничен 32Кб).

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

Еще одно интересное отличие ext4fs от ext3fs заключается в точности временной метки файлов. В ext3 размерность временной метки - одна секунда. Ext4fs смотрит в будущее: при непрекращающемся росте скоростей процессора и интерфейсов требуется более точное измерение. Поэтому в качестве размерности времени была взята одна наносекунда.

Хотя ext4fs включена в ядро Linux в версии 2.6.19, она уже может считаться стабильной. Эта система, разработка которой продолжается, является отправной точкой для создания журналируемой файловой системой будущего в Linux.

Двигаясь дальше

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

В этом обзоре будут подробно рассмотрены вопросы, рассмотрение которых в прошлой статье было поверхностным или отсутствовало вообще. Хотелось бы сразу сказать, что дисковая система NT настолько сложна, что говорить о ней можно еще достаточно долго - и эта статья не опишет всего, что можно было бы рассказать. Так что это лишь попытка координировано и подробно ответить на все вопросы, которые вызвала предыдущая публикация. Часть 4. Журналирование NTFS

Описание того простого факта, что NTFS является журналируемой системой, повергло многочисленных поклонников других файловых и операционных систем в искреннее возмущение. В многочисленных письмах, адресованных мне, NTFS называли системой с квази-журналированием или даже без журналирования вообще, ставя в противовес многочисленные файловые системы Unix. Мне пришло также много писем, указывающих на фатальные сбои NTFS, восстановится от которых не удалось - данные были потеряны. В данной части я попытаюсь, в меру своих сил и понимания, объяснить философию журналирования и средств защиты от сбоев NTFS, а также пояснить причины появления фатальных сбоев. Я постараюсь оправдать подход корпорации Microsoft, которая сделала всё именно так, как сделала - по крайней мере, я изложу причины реализованных технологических решений и те компромиссы, на которые пришлось пойти коллективу разработчиков NTFS.

Журналируемые операции

Прежде всего, хотелось бы рассказать о том, какие именно операции журналируются. Совершенно очевидно, что полный undo-файл, способный откатить абсолютно все операции, абсолютно невозможен как с точки зрения быстродействия, так и с точки зрения здравого смысла. Да, такое журналирование дало бы возможность восстановить большее число данных - например, при осуществлении перезаписи трех мегабайт в середине файла мы могли бы сначала сохранить новые данные в логе, затем переписать туда же предыдущие три мегабайта файла, и уж только затем осуществлять операции с реальными данными. Такой подход гарантировал бы полную определенность с судьбой информации - мы всегда смогли бы понять, какая часть данных уже записалась на диск, а какая находится в исходном, не обновленном состоянии. Он имеет всего один скромный недостаток - небольшая накладочка по быстродействию: для записи на диск трех мегабайт мы вынуждены будем осуществить разнообразные дисковые операции на объем в три раза больший - девять мегабайт. Да, полное журналирование также применяется - но в основном при работе с базами данных. Если вы желаете обеспечить полное журналирование каких-либо данных, вы можете поставить MS SQL или даже Oracle, который вообще не будет пользоваться средствами какой либо файловой системы и обеспечит сохранность ваших данных в любых разумных условиях. Сторонникам же полного журналирования файловой системы я могу ответить одно: решение сократить быстродействие операций записи в три раза, на мой взгляд, является слишком смелым для обязательного применения - и на домашних компьютерах, и на серверах.

Подход разработчиков NTFS был принципиально иным. Главный девиз был, видимо, не «надежность любой ценой», а «неизменность быстродействия». Журналирование просто не должно было помешать работе файловой системы. Первый логичный шаг - отменить полное журналирование как абсолютно неприемлемое с точки зрения быстродействия. В NTFS применяется журналирование логических структур, а не данных пользователя - отсюда и идет фраза, что сохранность данных не гарантируется, но, тем не менее, корректное состояние самой системы будет поддерживаться. То, что NTFS не журналирует данные файлов, приводит на практике к одному варианту потери данных - в том же гипотетическом случае записи трех мегабайт, в случае сбоя в процессе записи никогда уже не удастся установить, какая часть данных записалась, а какая осталась неизменна. Операции, которые, тем не менее, журналируются системой - это операции со структурами самой системы, то есть с файлами и каталогами: добавление файлов, переименование, перенос, создание и удаление (освобождение свободного места). Журналируются также и операции дефрагментации - то есть перемещения фрагментов файлов. Одним словом, все логические операции журналированы.

Отложенная запись и контрольные точки журналирования

Известно, что любая современная система для ускорения файловых операций вынуждена использовать кэширование, в том числе - кэширование операций записи. Так называемая отложенная запись - принцип кэширования, при котором данные, предназначенные для записи на диск, некоторое время сохраняются в кэше и лишь в свободное от других занятий время сохраняются физически. Отложенная запись существенно повышает эффективность дисковых операций, так как такое кэширование группирует множество операций в одну - это особенно эффективно, если запись производится в компактные участки диска. Еще один плюс отложенной записи - не мешать более нужным операциям чтения, и осуществлять запись только тогда, когда система свободна и ей не требуется доступ к диску для других нужд. Как согласовать отложенную запись с журналированием? Это довольно сложный вопрос, так как откладывание записи делает возможным потерю тех данных, которые находились в очереди на физическую запись и не успели записаться на диск до сбоя. Самое неприятное здесь даже не потеря данных, а то, что происходит рассогласование времени записи: какие-то служебные области могут быть обновлены, а какие-то смежные по смыслу - еще нет, так как их обновление могло отложится еще на пару секунд и не состоятся из-за сбоя.

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

Такой режим работы - с помощью записей и контрольных точек - с одной стороны, по прежнему гарантирует полностью корректную работу журналирования, а с другой стороны практически совершенно не приводит к замедлению работы: простановка контрольных точек производится, считай, мгновенно, а запись в журнал о начале операции соответствует по трудозатратам записи самих данных без отложенного кэширования. Реальная же запись, осуществляемая позже, в подавляющем числе случаев не мешает никаким операциям и не идет в ущерб производительности системы.

Проблемы отложенного журналирования: концепция дублирования информации

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

Рассмотрим такой случай: мы стираем файл. Журнал получил запись - «файл N стирается». Затем запаздывающему кэшу стало угодно осуществить сначала физическую пометку о том, что место, занимаемое файлом, освободилось, а уж только затем удалить файл из физических структур MFT и каталога. Допустим, диск находится в активной работе, и на освободившееся место тут же записывается другой файл. В этот момент происходит сбой. Система, загружаясь, исследует журнал и видит незавершенную операцию «файл N стирается» - вернее, как я уже описал выше, не незавершенную, а просто операцию, контрольная точка после которой отсутствует, что автоматически говорит о её незавершенности. Следующая фаза была бы «откат операции» - то есть восстановление файла. Одна незадача - место, физически занимаемое файлом, содержит уже другие данные.

Для недопущения таких ситуаций система, желающая ограничиться логическим журналированием, вынуждена применять принцип «временно занятого места». Место, освобожденное каким-либо объектом или записью о нем, не объявляется свободным до тех пор, пока физически не завершились все операции с логическими структурами. Данный механизм в NTFS, по видимому, не синхронизирован даже с проставлением контрольных точек, так как типичное время освобождения временно занятого места - около 30 секунд, точки же идут чаще.

Данный механизм применяется не только при стирании файла, но и при самых разных операциях: принцип журналирования - объект, убранный или перемещенный на новое место, должен иметь возможность корректно откатить своё «отбытие» - то есть данные, на которые ссылаются логические структуры удаляемого или перемещаемого объекта, необходимо еще на некоторое время зарезервировать как занятое место (диска/каталога). Это еще один шаг NTFS к полному журналированию, где специфическим журналом файловой информации служат сами данные освобождаемых областей, не уничтожаемые физически.

Ну хорошо, скажете вы, всё так замечательно - но почему же тогда разделы NTFS всё же летят?.. Сейчас я постараюсь объяснить принципы, которые приводит к тому, что вышеописанная модель сможет обеспечить полную восстанавливаемость логических структур.

  • Жесткий диск, в штатном режиме, должен записать именно то и именно туда, что и куда ему сказано было записать операционной системой. Данный принцип нарушается в случае, если система имеет ненадежный шлейф, процессор, память или контроллер - и это самая распространенная причина сбоев NTFS . Вам поможет: неразогнанный процессор, дорогая (качественная) память, хорошая материнская плата и протокол UDMA, обеспечивающий контроль и восстановление ошибок на участке контроллер-диск.
  • Жесткий диск, в случае аварии, отключения питания или получения от контроллера сигнала «сброс» (в случае внезапной перезагрузки материнской платы) обязан корректно завершить запись данных текущего физического сектора, если таковая производилась на момент аварии. Промежуточное состояние сектора не допускается . Вам помогут современные винчестеры, которые могут осуществить данную операцию даже в случае полного пропадания питания - у них хватит буферизированной в конденсаторах энергии, и их логика рассчитана на корректное поведение в случае отказа питания при записи.
  • Диск обязан мгновенно осуществить запись данных, отправленных с флагом «не кэшировать». Дело в том, что многие современные диски или контроллеры обеспечивают задержанную запись. Метафайлы NTFS обновляются в режиме «писать сразу», и контроллер/диск обязан выполнять это требование.
  • Жесткий диск обязан обеспечить чтение именно тех данных, которые были записаны. В случае невозможности прочесть данные выдается сигнал «ошибка». Диск не имеет права возвращать ошибочные данные (возможно, лишь частично некорректные) без сигнала об ошибке. Все современные жесткие диски имеют контрольные суммы секторов и жестко следуют этой логике поведения.

Четкое выполнение этих требований полностью гарантирует надежную работу NTFS. Структура файловой системы не будет содержать существенных ошибок даже после сбоя. Некоторые несущественные ошибки всё же появляются из-за того, что логика журналирования часто пытается завершить недоделанные операции - например, то же удаление файла - тогда как полную надежность обеспечивал бы только безусловный откат всего, что находится после последней контрольной точки. Малые несоответствия, рождающиеся из этих попыток, относятся к избыточной информации системы безопасности, не представляют никакой реальной опасности для данных - они действительно незначительны. Суть этих несоответствий чаще всего заключается в том, что на диске остаются «лишние» данные о тех режимах доступов, которые уже не понадобятся системе. Их прочистка - дело сугубо повышения производительности, как, например, дефрагментация, поэтому их наличие не является на самом деле ошибкой. В случае же обнаружения серьезных, реальных, проблем драйвер сам установит флажок тома «грязный», что проинструктирует систему проверить том при следующем его монтировании.

Я с большим сожалением должен сказать, что подавляющее большинство фатальных ошибок NTFS происходит по вине аппаратуры, не выполняющей эти элементарные требования. Да, я понимаю, абсолютной надежности не бывает. Но Microsoft пошел по пути разделения труда - за надежность вашей аппаратуры корпорация ответственности не несет. Мой компьютер на 70% не попадает в список совместимого с Windows 2000 оборудования, и то же самое можно сказать про почти любую реальную машину, функционирующую на просторах бывшего СССР. Особенно это относится к любителям разгонять компьютеры. Запомните раз и навсегда: вы с огромной степенью вероятности угробите NTFS в первый же год работы, если ваш процессор - 333, разогнанный на 415. И даже не раз... Мне очень жаль, но это действительно так. От любых сбоев корректного компьютера NTFS защитит, но вот от записи случайных данных в бут-сектор (копия которого, кстати, хранится в самом конце раздела) и в MFT система просто не страхуется . Извините.Часть 5. Программный RAID

Журналирование NTFS, как уже указывалось ранее, ни в коей мере не гарантирует от сбоев с потерей пользовательской информации. Между тем, NT предлагает несколько вариантов создания систем, где, в разумных условиях, гарантируется абсолютно всё. Можно также использовать большее число дисков для обеспечения не повышенной надежности, а, наоборот, повышенной скорости - или того и другого одновременно. О таких конфигурациях и пойдет речь в этой части статьи.

RAID (Redundant Array of Inexpensive Disks) - избыточный массив недорогих дисков. Технология, заключающаяся в одновременном использовании нескольких дисковых устройств для обеспечения характеристик надежности или скорости, отсутствующих у накопителей в отдельности.

Windows NT поддерживает на программном уровне три уровня RAID (так называются стратегии работы дисковых массивов), краткие характеристики которых сведены в следующую таблицу.

Быстродействие, по сравнению с обычными дисками Надежность Общее дисковое пространство
RAID 0
Параллельные диски
Существенное повышение производительности за счет дублирования дисков. 		Теоретически, в условиях некоторых (например, линейных) операций скорость чтения/записи, повышается во столько раз, сколько дисков задействовано в системе.
Реально увеличение быстродействия меньше - процентов 50%-90% от этого числа, что всё равно очень существенно. 		Понижается - фатальный сбой одного из дисков вызовет потерю данных. Равно сумме объемов составляющих массив дисков
RAID 1
 Зеркальные диски
Повышение надежности за счет дублирования информации. 		Скорость чтения теоретически повышается в число раз, соответствующее числу дисков. Реализованный в NT алгоритм не оптимален и приводит к гораздо более скромному увеличению быстродействия.
Скорость записи снижается, особенно в случае не до конца многозадачных дисковых контроллеров. 		Потеря данных возможна лишь в случае отказа сразу всех дисков или повреждения одного и того же участка информации на всех дисках. Остается неизменным (увеличение доступного дискового пространства за счет добавочных дисков не происходит).
RAID 5
Параллельные диски с четностью
Комбинация RAID 1 и RAID 0 - более эффективное использование дополнительных дисков. 		Скорость чтения повышается аналогичным RAID 0 образом, но число дисков, влияющих на быстродействие, следует уменьшить на один. Т.е. три диска RAID 5 обладают примерно такой же скоростью чтения, как и два диска RAID 0.
Скорость записи больше, чем у каждого диска в отдельности, но в целом невысока. 		Потеря данных возможна при выходе из строя двух дисков набора. Выход из строя одного из дисков существенно снижает скорость работы всего массива и является, по сути, аварийной ситуацией, хоть и без потери данных. Увеличивается.
Потеря от суммарного дискового объема составляет объем одного диска.
Например, пять дисков по 10 Гб дают RAID 5 объемом 40 Гб.

Остановимся подробнее на каждом из типов RAID-а.

RAID 0 (параллельные диски)

Данная стратегия направлена исключительно на повышение производительности. Несколько дисков хранят части дисковой структуры, которые собираются в один том лишь при наличии всех дисков массива.

Простейшая реализация RAID 0 из двух, например, дисков - указание на то, что каждый первый сектор тома (или любой другой объем информации) расположен на физическом диске A, а каждый второй - на диске B. Такая жесткая стратегия дает возможность избежать каких-либо дополнительных структур для хранения информации о том, где находятся какие данные. Скорость чтения, как и записи равны и зависят от числа дисков:

  • Быстродействие операции по работе со случайно расположенными данными подчиняются следующей схеме: всё зависит от вероятности того, что диск, на который мы хотим записать очередную порцию информации, свободен и готов мгновенно выполнить наш запрос. Например, RAID 0 из двух дисков: при осуществлении операции одним из дисков и поступлении дополнительной команды на работу с дисковой системой вероятность того, что для выполнения команды нам придется тревожить свободный в данный момент диск составляет 50% - это соответствует общему увеличению производительности случайных операций в полтора раза. Если же используется, к примеру, массив из десяти дисков, то вероятность какой-либо операции попасть на уже занятый накопитель составляет всего 10% - то есть производительность повышается в девять раз. Любителям строгой теории вероятности хочу заметить, что при таких подсчетах не учитываются некоторые факторы реальной работы систем, но цифры, тем не менее, имеют именно такой порядок.
  • Последовательные операции - чтение или запись последовательных участков - проходят практически всегда в n раз быстрее, чем на отдельном физическом диске, где n - число дисков в наборе. Это происходит потому, что вероятность в следующей операции попасть на свободный диск составляет 100% - ведь операции осуществляются последовательными блоками, которые равномерно раскидываются по дискам.

В качестве некоторого вывода - RAID 0 в любом случае существенно повышает быстродействие линейных операций, а с увеличением количества дисков, входящих в набор, существенно повышается скорость работы и со случайными данными. Для эффективной работы с дисковой системой в режиме RAID 0 просто необходим многозадачный режим работы контроллера, а желательно даже разных контроллеров, обеспечивающих доступ к разным дискам. Обязательным условием такой работы на интерфейсах IDE являются Bus-Mastering драйвера. Windows 2000 имеет встроенные драйвера, автоматически включающие этот режим для всех распространенных IDE контроллеров, для NT4 же могут понадобится дополнительные драйвера или изменения ключей реестра.

Надежность RAID 0 низка - отказ каждого диска является фатальным сбоем, точно так же, как и отказ накопителя в случае работы с обычными разделами.

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

RAID 1 (зеркальные диски)

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

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

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

RAID 5 (параллельные диски с четностью)

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

Концепцию четности можно понять, например, так: допустим, у нас есть пять бит - например, набор {0, 1, 1, 0, 1}. Мы формируем еще бит - бит четности, шестой, по такому правилу - если число единиц в предыдущих пяти битах четно, он будет равен 1, если нет - 0. В нашем случае число единиц равняется трем, т. е. нечетному числу - наш набор дополнился числом 0 и превратился в {0, 1, 1, 0, 1, }.

Допустим, набору данных причинен урон - {0, X, 1, 0, 1, }. С помощью правила, гласящего нам, что число единиц должно быть нечетно (последний бит), мы можем догадаться, что на месте X стояла единичка. Наш получившийся набор из шести бит (5 бит данных и 1 бит четности) избыточен и может грамотно скорректировать потерю любого из своих шести бит.

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

Возвращаемся к устройству RAID 5:

На рисунке изображен массив из пяти дисков. Видно, что каждый диск хранит четыре (условные) части реальных данных и один блок данных четности. Блок четности - скажем, 0 parity - способен восстановить потерю одного из фрагментов - любого, но одного - среди A0, B0, C0 и D0. Все вместе они, в свою очередь, способны восстановить блок 0 parity. Из изображенной структуры RAID видно, что данные, необходимые для полного восстановления всего столбика - то есть информации любого диска в случае сбоя - находятся на других дисках. В этом и заключается восстановление - при записи данных на любой из дисков обновляется также блок четности другого диска, соответствующего текущему блоку (например, при записи в A2 обновляется еще и блок 2 parity). Чтение данных с исправного диска происходит без использования блоков четности, т. е. почти в том же режиме, в каком работает RAID 0. Быстродействие RAID 5 в том виде, в каком это реализовано в NT, даже немного выше, чем у RAID 0.

Единственная накладка - в случае сбоя производительность массива снижается в огромное количество раз, так как при невозможности напрямую считать, например, D4, нужно будет восстанавливать данные этого блока с использованием всех других дисков одновременно - в нашем случае это будут блоки 4 parity, B4, C4 и E4.

Как видно, выход из строя одного из дисков RAID 5 является хоть и не фатальной, но резко аварийной ситуацией - хотя бы из соображений быстродействия чтения с массива. Нетрудно догадаться также, откуда исходит требования как минимум трех дисков - в случае двух накопителей RAID 5 просто вырождается в RAID 1, так как единственный способ создать информацию четности списка из одного элемента - это тем или иным образом дублировать этот элемент.

Допущения, обеспечивающие надежность

Как, опять? Да, опять - RAID также не является панацеей от абсолютно всех бед аппаратуры. Я должен сказать очень неожиданную для некоторых людей вещь: на ненадежном (некорректном) компьютере RAID грохнуть почти так же легко, как и однодисковую систему . RAID совершенно не спасет в следующих случаях:

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

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

И, напоследок, аксиома работы вышеописанных уровней RAID-а - любой сбой одного из дисков системы считается аварией, которую необходимо как можно быстрее ликвидировать. Особенно это относится к RAID 0 и RAID 5, штатная работа которых в условиях аварии одного из дисков практически невозможна.

Более подробно с системой программных RAID Windows NT можно ознакомится в справке к программе (или модулю - в Windows 2000) Disk Administrator, где, собственно, и создаются эти типы дисков. Обращаю ваше внимание, что способности рабочих станций в создании и использовании RAID-ов сильно ограничены - рабочая станция NT4, к примеру, поддерживает только RAID 0 (параллельные диски), тогда как все описанные варианты работают лишь на серверных вариантах операционных систем.Часть 6. Стратегия восстановления томов NTFS

Компьютер с NTFS не загружается. Что делать в этом случае? Как восстановить данные? Возможны два случая, действия в которых несколько отличаются друг от друга. К сожалению, простых стратегий восстановления NT и, соответственно, NTFS не существует - система достаточно сложна и не имеет простейших загрузочных средств, как, например, DOS или Windows95/98.

1. Первый вариант - система находилась на том же NTFS диске. Система просто-напросто перестала загружаться. Что же, тогда нам в 90% случаев предстоит поднимать не NTFS, а просто-напросто саму NT. Данная операция выходит далеко за рамки данной статьи, поэтому описываю лишь способ поставить рядом (на тот же NTFS раздел) еще одну систему NT, на которой можно будет в дальнейшем работать (и которая сможет считать ваши данные).

Пользователи NT4 смогут поставить систему прямо на NTFS, каким-либо образом загрузившись в программу установки.

Вам понадобится CD диск, который представляет собой корректный дистрибутив NT4. Такими свойствами, скорее всего, обладают диски, на которых NT4 находится в каталоге под именем i386, расположенном в корневом каталоге. Команда winnt /?, запущенная в этом каталоге, поможет вам выбрать ключи для создания трех загрузочных дискет, с которых можно будет запустить установку NT4 прямо на диск NTFS. Можно выбрать другой каталог установки - например, winnt2, чтобы затем попытаться реанимировать вашу собственную инсталляцию NT4, если вы видите подходы к этой специфической проблеме, которая под силу только специалистам. Устанавливаемая заново операционная система корректно впишет себя в список загрузи и нисколько не помешает вашему старому NT4.

В случае отсутствия CD в соответствующем формате (симптомы - надпись «вставьте диск с дистрибутивом NT4», не реагирующая на наличие вашего CD) - вам остается только поставить NT на какой-нибудь другой раздел, так как диск с NTFS недоступен из систем, отличных от NT.

Стоит учесть, что NT4 нельзя поставить на NTFS, прошедшую преобразование в новый формат от Windows2000. NT4 всё же читает такой NTFS, но только при наличии пакета обновления SP4 или выше.

Пользователи Windows2000 будут вынуждены найти загрузочный CD диск с Windows2000 (таким является официальный дистрибутив), который сам предложит вам либо поставить систему с нуля, или попытаться восстановить старую инсталляцию. Считать диск NTFS, с которым работал Windows2000, можно только самим Windows2000 или NT4 с пакетом обновления SP4 или выше.

Имейте в виду: восстановить какую-либо NT, не обладая либо диском аварийного восстановления (создается в NT4 командой rdisk /s, в Windows2000 - программой резервного копирования), практически невозможно - это работа для специалиста. К слову говоря, даже при наличии диска восстановления, вам скорее всего очень не понравится работа «восстановленной» системы, поэтому переустановка всей системы практически неизбежна. Если вы не являетесь опытным специалистом по NT, советую вам не пытаться пользоваться починяющими опциями установщика NT, т.к. результат вас, скорее всего, крайне не удовлетворит. Попытка, конечно, не пытка, но комплекс операций по полноценной реанимации системы очень велик и мало где описан, поэтому вы останетесь в каком-то промежуточном, хотя, наверное, и загружабельном, состоянии.

2. Система сама по себе работает, но доступа к диску (не загрузочному, а какому-то другому) нет. Disk Administrator показывает для вашего раздела тип unknown (неизвестный). В подавляющем большинстве случаев это означает, что каким-то образом была осуществлена перезапись загрузочной области (boot sector-а) раздела, и NT действительно не догадывается, что это вообще NTFS. Операционная система NT на всякий случай хранит копию загрузочного сектора в конце раздела - если его скопировать обратно в надлежащее место, в подавляющем большинстве случаев диск опознается как NTFS и починится самостоятельно.

Процесс вычисления правильных адресов достаточно сложен, поэтому я не буду его описывать. Для получения исчерпывающих инструкций для данного случая вам придется пойти на сайт MSDN и найти там статью Knowledge Base под номером Q153973 (скорее всего, вы сможете сделать это простым поиском) - после корректного следования этим инструкциям система по крайней мере опознается как NTFS, и дальнейшая судьба раздела зависит от внутренних средств восстановления NT, которые в таком случае возьмут его в оборот. Вам также поможет скромная на вид команда chkdsk, являющаяся неким ярлычком к системе внутреннего восстановления дисковых систем NT.

Журналирование NTFS

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

Отложенная запись и контрольные точки журналирования

Известно, что любая современная система для ускорения файловых операций вынуждена использовать кэширование, в том числе - кэширование операций записи. Так называемая отложенная запись - принцип кэширования, при котором данные, предназначенные для записи на диск, некоторое время сохраняются в КЭШе и лишь в свободное от других занятий время сохраняются физически. Отложенная запись существенно повышает эффективность дисковых операций, так как такое кэширование группирует множество операций в одну - это особенно эффективно, если запись производится в компактные участки диска. Еще один плюс отложенной записи - не мешать более нужным операциям чтения, и осуществлять запись только тогда, когда система свободна и ей не требуется доступ к диску для других нужд. Как согласовать отложенную запись с журналированием? Это довольно сложный вопрос, так как откладывание записи делает возможным потерю тех данных, которые находились в очереди на физическую запись и не успели записаться на диск до сбоя. Самое неприятное здесь даже не потеря данных, а то, что происходит рассогласование времени записи: какие-то служебные области могут быть обновлены, а какие-то смежные по смыслу - еще нет, так как их обновление могло отложится еще на пару секунд и не состоятся из-за сбоя.

NTFS справляется с этими проблемами с помощью смысловой интеграции операций отложенной записи и ведения журнала. При попытке начать журналируемую операцию в лог тут же записывается намерение - например, стереть файл. Это случается без задержек - на этом этапе отложенная запись не работает: это плата за присутствие журналирования, которой нельзя избежать. Но вот все остальные операции уже идут в задержанном режиме - то есть они могут состояться частично или не состоятся вообще. Единственная задержанная операция, работа которой несколько отличается от простой записи - запись в лог об удачном завершении предыдущих транзакций, так называемая контрольная точка. Через определенные промежутки времени - обычно через каждые несколько секунд - система в обязательном порядке сбрасывает абсолютно все задержанные операции на диск. После произведения этой операции в журнал записывается простейшая запись - контрольная точка, - которая говорит о том, что все предыдущие операции выполнены корректно на всех уровнях - как на логическом, так и на физическом.

Такой режим работы - с помощью записей и контрольных точек - с одной стороны, по прежнему гарантирует полностью корректную работу журналирования, а с другой стороны практически совершенно не приводит к замедлению работы: простановка контрольных точек производится, считай, мгновенно, а запись в журнал о начале операции соответствует по трудозатратам записи самих данных без отложенного кэширования. Реальная же запись, осуществляемая позже, в подавляющем числе случаев не мешает никаким операциям и не идет в ущерб производительности системы.