Что такое журналируемая файловая система

Обновлено: 04.07.2024

Каждая операционная система использует собственные файловые системы для хранения данных. Для Windows это NTFS, в macOS применяется APFS, а большинство Linux дистрибутивов полагаются на Ext4. Несмотря на то, что все эти файловые системы отличаются друг от друга на фундаментальном уровне, у них есть и нечто общее – все они являются журналируемыми файловыми системами.

Давайте немного поговорим о журналировании и том, как оно влияет на повседневную работу.

Что такое журналирование?

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

К примеру, удаление файла в файловой системе Unix включает в себя три шага:

Удаление его записи в директории
Освобождение индексного дескриптора в пул свободных дескрипторов
Возврат всех дисковых блоков в пул свободных дисковых блоков

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

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

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

Заключение

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

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

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

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

Но есть еще одна проблема: файловые системы ext3 и ext4 по умолчанию не используют барьеры. Опция есть, но если администратор не включил их явно, то эти файловые системы работают без барьеров, хотя в некоторых дистрибутивах (например, SUSE) значения по умолчанию другие. Эрик Сандин (Eric Sandeen) недавно решил, что эту ситуацию надо изменить и сделал патч, модифицирующий настройки по умолчанию для ext3 и ext4. И тогда началось бурное обсуждение.

Эндрю Мортон (Andrew Morton) очень подробно ответил, почему значение по умолчанию именно такое:

В прошлый раз, когда мы пытались это изменить, производительность на многих нагрузках ухудшилась на 30%, поэтому я в ужасе выбросил все эти патчи. Я думаю, что мы не можем пойти на это и замедлить работу всех машин настолько серьезно…
Здесь нет идеальных решений, и я склоняюсь к тому, чтобы не будить эту спящую собаку и оставить параметры по умолчанию на усмотрение разработчиков дистрибутивов.

Но это не просто везение. Тед Тсо (Ted Ts'o) объясняет это тем, что журнал ext3 / ext4 обычно расположен непрерывно. Во-первых, драйвер файловой системы пытается создать его непрерывным. Во-вторых, журнал обычно создается одновременно с файловой системой, когда легко найти непрерывное пространство. Непрерывность и упорядоченность полезны не только для производительности, но и для предотвращения переупорядочивания. Обычно коммит блок будет размещаться сразу после остальных данных в журнале, поэтому у диска нет причин для переупорядочивания. Коммит блок естественным образом записывается на диск сразу после остальных записей журнала.

Тем не менее никто не утверждает, что так будет всегда. Дисковые накопители могут вести себя и по-другому. Кроме того, журнал представляет собой кольцевой буфер. Поэтому когда транзакция записывается в конец журнала, то коммит блок может оказаться в более раннем блоке, перед другими записями журнала. Так что вероятность повреждения есть всегда. На самом деле, у Криса Мэйсона (Chris Mason) есть для этого тесты. Нет сомнений, что работа без барьеров менее безопасна, чем с ними.

Если вы готовы принять удар по производительности, то можете включить барьеры. В том случае, конечно, когда ваша файловая система не основана на LVM (как в некоторых дистрибутивах по умолчанию). Оказывается, device mapper не поддерживает барьеры. В остальных случаях было бы неплохо уменьшить снижение производительности. И, похоже, это можно сделать.

Текущая реализация ext3 (когда барьеры включены) для каждой транзакции выполняет следующую последовательность операций:

Данные записываются в журнал

Записывается коммит блок

Выполняется следующий барьер

Позже метаданные сбрасываются на диск

В ext4 первый барьер (шаг 2) можно опустить, так как файловая система ext4 поддерживает контрольные суммы в журнале.

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

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

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

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

Похоже, пришло время подумать, как сделать стоимость барьеров приемлемой. Тед Тсо, кажется, считает аналогично:

Я думаю, что мы должны включить барьеры в ext3/4, а затем работать над уменьшением накладных расходов в ext4 / jbd2. Скорее всего, подавляющее большинство систем не работают в условиях, подобных тем, которые использовал Крис для демонстрации проблемы и безопасность файловой системы по умолчанию должна быть в приоритете.

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

Интересно развиваться в данном направлении? Запишитесь на бесплатный Demo-урок «Конфигурирование web-сервера (Apache, Nginx, балансировка Nginx)» и участвуйте в трансляции «Работа с логами в Linux», которую проведёт Павел Викирюк — оператор связи MVNO, DevOps-инженер.

Перевод поста HTG Explains: Which Linux File System Should You Choose? (2010 год) с некоторыми дополнениями и уточнениями.

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

Журналирование в том или ином виде применяется практически во всех современных файловых системах.