Войти
Журнальная файловая система является файловой системой, которая отслеживает изменения еще не приверженных основной часть файловой системы пути записи цели таких изменений в структуре данных, известные как « журнал », который обычно является кольцевым журнал. В случае сбоя системы или сбоя питания такие файловые системы могут быть возвращены в оперативный режим быстрее с меньшей вероятностью повреждения.
В зависимости от фактической реализации журналируемая файловая система может отслеживать только сохраненные метаданные, что приводит к повышению производительности за счет увеличения вероятности повреждения данных. В качестве альтернативы журналируемая файловая система может отслеживать как сохраненные данные, так и связанные с ними метаданные, в то время как некоторые реализации позволяют выбирать поведение в этом отношении.
В 1990 году IBM представила JFS в AIX 3.1 как одну из первых коммерческих файловых систем UNIX, в которой реализовано журналирование. В следующем году эта идея была популяризирована в широко цитируемой статье о файловых системах с журнальной структурой. Впоследствии это было реализовано в Microsoft, Windows NT «s NTFS файловой системы в 1993 году и в Linux » с ext3 файловой системы в 2001 году.
Обновление файловых систем для отражения изменений в файлах и каталогах обычно требует множества отдельных операций записи. Это делает возможным для прерывания (например, сбоя питания или системы аварии ) между записями, чтобы оставить структуры данных в недействительном промежуточном состоянии.
Например, удаление файла в файловой системе Unix включает три шага:
Если сбой происходит после шага 1 и до шага 2, будет потерянный индексный дескриптор и, следовательно, утечка памяти ; если между шагами 2 и 3 происходит сбой, то блоки, ранее использовавшиеся файлом, не могут использоваться для новых файлов, что эффективно снижает емкость хранилища файловой системы. Перестановка ступеней тоже не помогает. Если шаг 3 предшествует шагу 1, сбой между ними может позволить повторно использовать блоки файла для нового файла, то есть частично удаленный файл будет содержать часть содержимого другого файла, и изменения любого файла будут отображаться в обоих. С другой стороны, если шаг 2 предшествует шагу 1, сбой между ними приведет к тому, что файл станет недоступным, несмотря на то, что кажется, что он существует.
Обнаружение и устранение таких несоответствий обычно требует полного обхода его структур данных, например, с помощью такого инструмента, как fsck (средство проверки файловой системы). Обычно это необходимо сделать до следующего монтирования файловой системы для доступа для чтения и записи. Если файловая система велика и если пропускная способность ввода-вывода относительно мала, это может занять много времени и привести к более длительным простоям, если остальная часть системы не сможет вернуться в оперативный режим.
Чтобы предотвратить это, журналируемая файловая система выделяет специальную область - журнал, в который записываются изменения, которые она вносит заранее. После сбоя восстановление просто включает чтение журнала из файловой системы и воспроизведение изменений из этого журнала до тех пор, пока файловая система снова не станет согласованной. Таким образом, изменения называются атомарными (не делимыми) в том смысле, что они либо успешны (изначально выполнены успешно, либо полностью воспроизводятся во время восстановления), либо не воспроизводятся вообще (пропускаются, потому что они еще не были полностью записаны в журнал перед тем, как произошла авария).
Некоторые файловые системы позволяют журналу увеличиваться, сжиматься и перераспределяться как обычный файл, в то время как другие помещают журнал в непрерывную область или в скрытый файл, который гарантированно не перемещается и не меняет размер во время монтирования файловой системы. Некоторые файловые системы могут также разрешать внешние журналы на отдельном устройстве, таком как твердотельный накопитель или энергонезависимое ОЗУ с резервным питанием от батареи. Сами изменения в журнале могут регистрироваться для дополнительной избыточности, или журнал может быть распределен по нескольким физическим томам для защиты от сбоя устройства.
Внутренний формат журнала должен защищать от сбоев во время записи в сам журнал. Многие реализации журнала (например, уровень JBD2 в ext4 ) заключают в скобки каждое зарегистрированное изменение с контрольной суммой, понимая, что сбой оставит частично записанное изменение с отсутствующей (или несовпадающей) контрольной суммой, которую можно просто игнорировать при воспроизведении журнала в следующий перемонтировать.
В физическом журнале записывается предварительная копия каждого блока, которая позже будет записана в основную файловую систему. Если во время записи в основную файловую систему происходит сбой, запись может быть просто воспроизведена до завершения при следующем монтировании файловой системы. Если во время записи в журнал происходит сбой, то при частичной записи будет отсутствовать или не совпадать контрольная сумма, и ее можно будет проигнорировать при следующем монтировании.
Физические журналы налагают значительное снижение производительности, поскольку каждый измененный блок должен дважды фиксироваться в хранилище, но может быть приемлемым, когда требуется абсолютная защита от сбоев.
А логический журнал хранит только изменения файла метаданных в журнале, и торгует отказоустойчивость существенно более высокую производительность записи. Файловая система с логическим журналом по-прежнему быстро восстанавливается после сбоя, но может привести к рассинхронизации незарегистрированных файловых данных и записанных метаданных друг с другом, что приведет к повреждению данных.
Например, добавление к файлу может включать три отдельных записи:
В журнале, содержащем только метаданные, шаг 3 не регистрируется. Если шаг 3 не был выполнен, но шаги 1 и 2 воспроизводятся во время восстановления, файл будет добавлен с мусором.
Кэш записи в большинстве операционных систем сортирует свои записи (с использованием алгоритма лифта или какой-либо подобной схемы), чтобы максимизировать пропускную способность. Чтобы избежать опасности неупорядоченной записи с журналом, состоящим только из метаданных, записи для файловых данных должны быть отсортированы так, чтобы они фиксировались в хранилище до связанных с ними метаданных. Это может быть сложно реализовать, потому что для этого требуется координация в ядре операционной системы между драйвером файловой системы и кешем записи. Опасность неупорядоченной записи также может возникнуть, если устройство не может записывать блоки немедленно в свое базовое хранилище, то есть оно не может сбросить свой кэш записи на диск из-за включения отложенной записи.
Еще больше усложняет ситуацию то, что у многих запоминающих устройств есть собственные кэши записи, в которых они могут агрессивно переупорядочивать записи для повышения производительности. (Это особенно характерно для магнитных жестких дисков, которые имеют большие задержки поиска, которые можно минимизировать с помощью лифтовой сортировки.) Некоторые журналирующие файловые системы консервативно предполагают, что такое переупорядочение записи происходит всегда, и жертвуют производительностью ради правильности, заставляя устройство сбрасывать свои данные. кешировать в определенных точках журнала (называемых барьерами в ext3 и ext4 ).
Некоторые реализации UFS избегают журналирования и вместо этого реализуют мягкие обновления : они упорядочивают свои записи таким образом, чтобы файловая система на диске никогда не была несогласованной или что единственное несоответствие, которое может возникнуть в случае сбоя, - это утечка хранилища. Чтобы исправить эти утечки, карта свободного пространства сверяется с полным обходом файловой системы при следующем монтировании. Это сбор мусора, как правило, выполняется в фоновом режиме.
В файловых системах с журнальной структурой штраф за двойную запись не применяется, потому что журнал сам является файловой системой: он занимает все устройство хранения и структурирован так, что по нему можно перемещаться, как в обычной файловой системе.
Файловые системы с полным копированием при записи (такие как ZFS и Btrfs ) избегают изменений файловых данных на месте, записывая данные во вновь выделенных блоках с последующими обновленными метаданными, которые будут указывать на новые данные и отвергать старые, а затем метаданными, указывающими на это, и так далее до суперблока или корня иерархии файловой системы. Он имеет те же свойства сохранения правильности, что и журнал, без накладных расходов, связанных с двойной записью.
