Журналируемая файловая система — это файловая система , которая отслеживает изменения, еще не зафиксированные в основной части файловой системы , записывая цель таких изменений в структуру данных, известную как « журнал », который обычно представляет собой циклический журнал . В случае сбоя системы или сбоя питания такие файловые системы можно быстрее восстановить в рабочем режиме с меньшей вероятностью повреждения . [1] [2]
В зависимости от фактической реализации журналируемая файловая система может отслеживать только сохраненные метаданные , что приводит к повышению производительности за счет увеличения вероятности повреждения данных. Альтернативно, журналируемая файловая система может отслеживать как сохраненные данные, так и связанные с ними метаданные, хотя некоторые реализации допускают возможность выбора поведения в этом отношении. [3]
В 1990 году IBM представила JFS в AIX 3.1 как одну из первых коммерческих файловых систем UNIX, реализовавших журналирование. [4] В следующем году эта идея была популяризирована в широко цитируемой статье о файловых системах с журнальной структурой. [5] Впоследствии это было реализовано в файловой системе NTFS Microsoft Windows NT в 1993 году , в файловой системе Apple HFS Plus в 1998 году и в файловой системе ext3 Linux в 2001 году. [6]
Обновление файловых систем для отражения изменений в файлах и каталогах обычно требует множества отдельных операций записи. Это позволяет в случае прерывания (например, сбоя питания или сбоя системы ) между операциями записи оставить структуры данных в недопустимом промежуточном состоянии. [1]
Например, удаление файла в файловой системе Unix состоит из трех шагов: [7]
Если сбой произойдет после шага 1 и до шага 2, будет потерянный индексный дескриптор и, следовательно, произойдет утечка памяти ; если сбой происходит между шагами 2 и 3, то блоки, ранее использованные файлом, не могут быть использованы для новых файлов, что существенно уменьшает емкость файловой системы. Перестановка шагов тоже не помогает. Если шаг 3 предшествует шагу 1, сбой между ними может позволить повторно использовать блоки файла для нового файла, то есть частично удаленный файл будет содержать часть содержимого другого файла, и изменения в любом файле будут отображаться в обоих. С другой стороны, если шаг 2 предшествует шагу 1, сбой между ними приведет к тому, что файл станет недоступным, несмотря на то, что он существует.
Обнаружение и восстановление таких несоответствий обычно требует полного обхода структур данных, например, с помощью такого инструмента, как fsck (программа проверки файловой системы). [2] Обычно это необходимо сделать до следующего монтирования файловой системы для доступа для чтения и записи. Если файловая система большая и пропускная способность ввода-вывода относительно небольшая, это может занять много времени и привести к более длительным простоям, если это заблокирует возвращение остальной части системы в режим онлайн.
Чтобы предотвратить это, журналируемая файловая система выделяет специальную область — журнал, в котором заранее записываются изменения, которые она произведет. После сбоя восстановление просто включает в себя чтение журнала из файловой системы и воспроизведение изменений из этого журнала до тех пор, пока файловая система снова не станет согласованной. Таким образом, изменения называются атомарными (неделимыми), поскольку они либо успешны (первоначально выполнены или полностью воспроизводятся во время восстановления), либо не воспроизводятся вообще (пропускаются, поскольку они еще не были полностью записаны в журнал до момента изменения). произошел сбой).
Некоторые файловые системы позволяют журналу увеличиваться, уменьшаться и перераспределяться так же, как обычный файл, в то время как другие помещают журнал в непрерывную область или в скрытый файл, который гарантированно не перемещается и не меняет размер во время монтирования файловой системы. Некоторые файловые системы также могут разрешать ведение внешних журналов на отдельном устройстве, например на твердотельном диске или энергонезависимой оперативной памяти с батарейным питанием. Изменения в журнале сами могут регистрироваться для дополнительной избыточности, или журнал может быть распределен по нескольким физическим томам для защиты от сбоя устройства.
Внутренний формат журнала должен защищать от сбоев во время записи в сам журнал. Многие реализации журнала (например, уровень JBD2 в ext4 ) заключают в скобки каждое зарегистрированное изменение с помощью контрольной суммы, понимая, что сбой приведет к частично записанному изменению с отсутствующей (или несовпадающей) контрольной суммой, которую можно просто игнорировать при воспроизведении журнала в следующая перемонтировка.
В физическом журнале регистрируется предварительная копия каждого блока, который позже будет записан в основную файловую систему. Если при записи в основную файловую систему произошел сбой, запись можно просто повторить до завершения при следующем монтировании файловой системы. Если при записи записи в журнал произойдет сбой, контрольная сумма частичной записи будет отсутствовать или не совпадать, и ее можно будет игнорировать при следующем монтировании.
Физические журналы налагают значительное снижение производительности, поскольку каждый измененный блок должен быть дважды зафиксирован в хранилище, но это может быть приемлемо, когда требуется абсолютная защита от ошибок. [8]
Логический журнал хранит в журнале только изменения метаданных файлов и обеспечивает отказоустойчивость для существенно более высокой производительности записи. [9] Файловая система с логическим журналом по-прежнему быстро восстанавливается после сбоя, но может привести к тому, что нежурнализируемые файловые данные и журналируемые метаданные рассинхронизируются друг с другом, что приведет к повреждению данных.
Например, добавление к файлу может включать три отдельные записи:
В журнале, содержащем только метаданные, шаг 3 не будет зарегистрирован. Если шаг 3 не был выполнен, но при восстановлении повторяются шаги 1 и 2, то в файл будет добавлен мусор.
Кэш записи в большинстве операционных систем сортирует записи (используя алгоритм лифта или другую подобную схему) для максимизации пропускной способности. Чтобы избежать опасности неправильной записи в журнале, содержащем только метаданные, записи файловых данных должны быть отсортированы таким образом, чтобы они фиксировались в хранилище до связанных с ними метаданных. Это может быть сложно реализовать, поскольку для этого требуется координация внутри ядра операционной системы между драйвером файловой системы и кэшем записи. Опасность записи вне порядка также может возникнуть, если устройство не может немедленно записывать блоки в базовое хранилище, то есть оно не может сбросить свой кэш записи на диск из-за включенной отложенной записи.
Ситуация усложняется тем, что многие устройства хранения данных имеют собственные кэши записи, в которых они могут агрессивно переупорядочивать записи для повышения производительности. (Это особенно часто встречается на магнитных жестких дисках, которые имеют большие задержки поиска, которые можно минимизировать с помощью лифтовой сортировки.) Некоторые журналируемые файловые системы консервативно предполагают, что такое изменение порядка записи происходит всегда, и жертвуют производительностью ради правильности, заставляя устройство сбрасывать свои данные. кэшировать в определенных точках журнала (называемых барьерами в ext3 и ext4 ). [10]
Некоторые реализации UFS избегают ведения журнала и вместо этого реализуют мягкие обновления : они упорядочивают свои записи таким образом, чтобы файловая система на диске никогда не была противоречивой или что единственное несоответствие, которое может возникнуть в случае сбоя, — это утечка памяти. Чтобы устранить эти утечки, карта свободного пространства сверяется с полным обходом файловой системы при следующем монтировании. Эта сборка мусора обычно выполняется в фоновом режиме. [11]
В файловых системах с журнальной структурой штраф за двойную запись не применяется, поскольку журнал сам по себе является файловой системой: он занимает все устройство хранения и структурирован так, что его можно просматривать, как и в обычной файловой системе.
Файловые системы с полным копированием при записи (такие как ZFS и Btrfs ) позволяют избежать изменений в данных файла на месте, записывая данные в вновь выделенные блоки с последующим обновлением метаданных, которые будут указывать на новые данные и отказываться от старых. метаданными, указывающими на это, и так далее до суперблока или корня иерархии файловой системы. Он имеет те же свойства сохранения корректности, что и журнал, без дополнительных затрат на двойную запись.