Журнальная файловая система является файловой системой , которая отслеживает изменения еще не приверженных основной часть файловой системы пути записи намерения таких изменений в структуре данных , известные как « журнал », который обычно является кольцевым журнал . В случае сбоя системы или сбоя питания такие файловые системы могут быть возвращены в оперативный режим быстрее с меньшей вероятностью повреждения. [1] [2]
В зависимости от фактической реализации файловая система с журналированием может отслеживать только сохраненные метаданные , что приводит к повышению производительности за счет увеличения вероятности повреждения данных. В качестве альтернативы журналируемая файловая система может отслеживать как сохраненные данные, так и связанные с ними метаданные, в то время как некоторые реализации позволяют выбирать поведение в этом отношении. [3]
История [ править ]
В 1990 году IBM JFS , представленная в AIX 3.1, была одной из первых коммерческих файловых систем UNIX, в которых реализовано журналирование. Впоследствии это было реализовано в Microsoft, Windows NT «s NTFS файловой системы в 1993 году и в Linux » с ext3 файловой системы в 2001 году [4]
Обоснование [ править ]
Обновление файловых систем для отражения изменений в файлах и каталогах обычно требует множества отдельных операций записи. Это делает возможным для прерывания (например , сбоя питания или системы аварии ) между записями , чтобы оставить структуры данных в недействительном промежуточном состоянии. [1]
Например, удаление файла в файловой системе Unix включает три шага: [5]
- Удаление записи в каталоге.
- Освобождение индексного дескриптора в пул свободных индексных дескрипторов.
- Возврат всех дисковых блоков в пул свободных дисковых блоков.
Если сбой происходит после шага 1 и до шага 2, будет потерянный индексный дескриптор и, следовательно, утечка памяти ; если между шагами 2 и 3 происходит сбой, то блоки, ранее использовавшиеся файлом, не могут использоваться для новых файлов, что эффективно снижает емкость хранилища файловой системы. Перестановка ступеней тоже не помогает. Если шаг 3 предшествовал шагу 1, сбой между ними может позволить повторно использовать блоки файла для нового файла, что означает, что частично удаленный файл будет содержать часть содержимого другого файла, и изменения любого файла будут отображаться в обоих. С другой стороны, если шаг 2 предшествует шагу 1, сбой между ними приведет к тому, что файл станет недоступным, несмотря на то, что кажется, что он существует.
Обнаружение и устранение таких несоответствий обычно требует полного обхода его структур данных, например, с помощью такого инструмента, как fsck (средство проверки файловой системы). [2] Обычно это необходимо сделать до следующего монтирования файловой системы для доступа для чтения и записи. Если файловая система велика и если пропускная способность ввода-вывода относительно мала, это может занять много времени и привести к более длительным простоям, если остальная часть системы не сможет вернуться в оперативный режим.
Чтобы предотвратить это, журналируемая файловая система выделяет специальную область - журнал, в который записываются изменения, которые она вносит заранее. После сбоя восстановление просто включает чтение журнала из файловой системы и воспроизведение изменений из этого журнала до тех пор, пока файловая система снова не станет согласованной. Таким образом, изменения называются атомарными (не делимыми) в том смысле, что они либо успешны (изначально выполнены успешно, либо полностью воспроизводятся во время восстановления), либо не воспроизводятся вообще (пропускаются, потому что они еще не были полностью записаны в журнал до того, как произошла авария).
Методы [ править ]
Некоторые файловые системы позволяют журналу увеличиваться, сжиматься и перераспределяться как обычный файл, в то время как другие помещают журнал в непрерывную область или в скрытый файл, который гарантированно не перемещается и не меняет размер во время монтирования файловой системы. Некоторые файловые системы могут также разрешать внешние журналы на отдельном устройстве, таком как твердотельный накопитель или энергонезависимое ОЗУ с резервным питанием от батареи. Сами изменения в журнале могут регистрироваться для дополнительной избыточности, или журнал может быть распределен по нескольким физическим томам для защиты от сбоя устройства.
Внутренний формат журнала должен защищать от сбоев во время записи в сам журнал. Многие реализации журнала (например, уровень JBD2 в ext4 ) заключают в скобки каждое зарегистрированное изменение с контрольной суммой, понимая, что сбой оставит частично записанное изменение с отсутствующей (или несовпадающей) контрольной суммой, которую можно просто игнорировать при воспроизведении журнала в следующий перемонтировать.
Физические журналы [ править ]
В физическом журнале записывается предварительная копия каждого блока, которая позже будет записана в основную файловую систему. Если во время записи в основную файловую систему происходит сбой, запись можно просто воспроизвести до завершения при следующем монтировании файловой системы. Если во время записи в журнал происходит сбой, то при частичной записи будет отсутствовать или не совпадать контрольная сумма, и ее можно будет проигнорировать при следующем монтировании.
Физические журналы налагают значительное снижение производительности, потому что каждый измененный блок должен дважды фиксироваться в хранилище, но может быть приемлемым, когда требуется абсолютная защита от сбоев. [6]
Логические журналы [ править ]
А логический журнал хранит только изменения файла метаданных в журнале, и торгует отказоустойчивость существенно более высокую производительность записи. [7] Файловая система с логическим журналом по-прежнему быстро восстанавливается после сбоя, но может привести к рассинхронизации незарегистрированных файловых данных и записываемых метаданных друг с другом, что приведет к повреждению данных.
Например, добавление к файлу может включать три отдельных записи:
- В файле инод , отметить в метаданных файла , что его размер увеличился.
- Карта свободного пространства, чтобы отметить выделение пространства для добавляемых данных.
- Вновь выделенное пространство для записи добавленных данных.
В журнале, содержащем только метаданные, шаг 3 не регистрируется. Если шаг 3 не был выполнен, но шаги 1 и 2 воспроизводятся во время восстановления, файл будет добавлен с мусором.
Опасности записи [ править ]
Кэш записи в большинстве операционных систем сортирует свои записи (с использованием алгоритма лифта или какой-либо подобной схемы) для максимизации пропускной способности. Чтобы избежать опасности неупорядоченной записи с журналом, состоящим только из метаданных, записи для файловых данных должны быть отсортированы так, чтобы они фиксировались в хранилище до связанных с ними метаданных. Это может быть сложно реализовать, потому что для этого требуется координация в ядре операционной системы между драйвером файловой системы и кешем записи. Опасность неупорядоченной записи также может возникнуть, если устройство не может записывать блоки немедленно в свое базовое хранилище, то есть оно не может сбросить свой кэш записи на диск из-за включения отложенной записи.
Еще больше усложняет ситуацию то, что у многих запоминающих устройств есть собственные кэши записи, в которых они могут агрессивно переупорядочивать записи для повышения производительности. (Это особенно часто встречается на магнитных жестких дисках, которые имеют большие задержки поиска, которые можно минимизировать с помощью лифтовой сортировки.) Некоторые журналирующие файловые системы консервативно предполагают, что такое переупорядочение записи происходит всегда, и жертвуют производительностью ради правильности, заставляя устройство сбрасывать свою кэшировать в определенных точках журнала (называемых барьерами в ext3 и ext4 ). [8]
Альтернативы [ править ]
Мягкие обновления [ править ]
Некоторые реализации UFS избегают журналирования и вместо этого реализуют мягкие обновления : они упорядочивают свои записи таким образом, чтобы файловая система на диске никогда не была противоречивой или что единственная несогласованность, которая может возникнуть в случае сбоя, - это утечка хранилища. Чтобы исправить эти утечки, карта свободного пространства сверяется с полным обходом файловой системы при следующем монтировании. Это сбор мусора , как правило , выполняется в фоновом режиме. [9]
Файловые системы с лог-структурой [ править ]
В файловых системах с журнальной структурой штраф за двойную запись не применяется, потому что журнал сам является файловой системой: он занимает все устройство хранения и структурирован так, что по нему можно перемещаться, как в обычной файловой системе.
Файловые системы с функцией копирования при записи [ править ]
Файловые системы с полным копированием при записи (такие как ZFS и Btrfs ) избегают изменений файловых данных на месте, записывая данные во вновь выделенные блоки, за которыми следуют обновленные метаданные, которые будут указывать на новые данные и отказываться от старых, а затем метаданными, указывающими на это, и так далее до суперблока или корня иерархии файловой системы. Он имеет те же свойства сохранения правильности, что и журнал, без накладных расходов, связанных с двойной записью.
См. Также [ править ]
- КИСЛОТА
- Сравнение файловых систем
- База данных
- Журнал намерений
- Журналируемая файловая система (JFS) - файловая система, созданная IBM.
- Обработка транзакции
- Управление версиями файловой системы
Ссылки [ править ]
- ^ a b Джонс, М. Тим (4 июня 2008 г.), Анатомия журнальных файловых систем Linux , IBM DeveloperWorks , заархивировано из оригинала 21 февраля 2009 г. , получено 13 апреля 2009 г.
- ^ a b Arpaci-Dusseau, Remzi H .; Arpaci-Dusseau, Andrea C. (21 января 2014 г.), Crash Consistency: FSCK and Journaling (PDF) , Arpaci-Dusseau Books, архив (PDF) из оригинала 24 января 2014 г. , извлечен 22 января 2014 г.
- ^ "tune2fs (8) - справочная страница Linux" . linux.die.net . Архивировано 25 февраля 2015 года . Проверено 20 февраля 2015 года .
- ^ " ' 2.4.15-final' - MARC" . marc.info . Проверено 24 марта 2018 года .
- ^ Файловые системы от Tanenbaum, AS (2008). Современные операционные системы (3-е изд., С. 287). Река Аппер Сэдл, штат Нью-Джерси: Prentice Hall.
- ^ Твиди, Стивен (2000), «Ext3, журналируемая файловая система», Труды Оттавского симпозиума Linux : 24–29
- ↑ Прабхакаран, Виджаян; Arpaci-Dusseau, Andrea C; Arpaci-Dusseau, Remzi H, «Анализ и эволюция журнальных файловых систем» (PDF) , Ежегодная техническая конференция USENIX 2005 г. , Ассоциация USENIX, архив (PDF) из оригинала 26 сентября 2007 г. , извлечено 27 июля 2007 г. .
- ↑ Корбет, Джонатан (21 мая 2008 г.), Барьеры и журналирование файловых систем , заархивировано из оригинала 14 марта 2010 г. , получено 6 марта 2010 г.
- ^ Зельцер, Марго I; Гангер, Грегори Р.; МакКусик, М. Кирк, «Ведение журнала и мягкие обновления: асинхронная защита метаданных в файловых системах» , Ежегодная техническая конференция USENIX 2000 г. , Ассоциация USENIX, заархивировано из оригинала 26 октября 2007 г. , получено 27 июля 2007 г..
