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

Обновлено: 21.11.2024

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

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

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

Зачем использовать ведение журнала

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

Например, удаление файла в файловой системе Unix состоит из трех шагов:

  1. Удаление его записи в каталоге.
  2. Выпуск индексного дескриптора в пул свободных индексных дескрипторов.
  3. Возврат всех дисковых блоков в пул свободных дисковых блоков.

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

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

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

Как ведется журнал

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

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

Физические журналы

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

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

Логические журналы

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

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

  1. Инод файла, чтобы отметить в метаданных файла, что его размер увеличился.
  2. Карта свободного пространства для выделения места для добавляемых данных.
  3. Вновь выделенное пространство для фактической записи добавленных данных.

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

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

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

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

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

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

Наиболее часто используемой журналируемой файловой системой для Linux является третья расширенная файловая система (ext3fs), которая была добавлена ​​в ядро ​​с версии 2.4.16 (выпущенной в январе 1993 г.). По сути, это расширение ext2fs, к которому были добавлены возможности журналирования, и оно обеспечивает такую ​​же высокую степень надежности благодаря полностью проверенному на практике характеру лежащего в его основе ext2. Также предусмотрена возможность преобразования разделов ext2 в ext3 и наоборот без необходимости резервного копирования данных и переразметки. При необходимости раздел ext3 может быть смонтирован даже старым ядром, не поддерживающим ext3; это потому, что он будет восприниматься как еще один обычный раздел ext2, и журнал будет проигнорирован.

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

Как и в случае с ext2, ReiserFS изначально разрабатывалась для использования в Linux. Однако, в отличие от ext3, она также была разработана с нуля как журналируемая файловая система, а не как надстройка к существующей файловой системе, и поэтому она широко считалась самой передовой из собственных журналируемых файловых систем Linux. Особенности включают в себя высокую скорость, отличную стабильность и возможность упаковывать небольшие файлы на меньшем дисковом пространстве, чем это возможно со многими другими файловыми системами. Неясно, какое влияние на будущее этой файловой системы может оказать арест Ганса Райзера в октябре 2006 г. как подозреваемого в убийстве его жены, хотя вскоре после этого Novell решила заменить ReiserFS по умолчанию на ext3 в своей SUSE. Версия Linux Enterprise.

JFS изначально была разработана IBM в середине 1990-х годов для своей операционной системы AIX UNIX. Позже он был портирован на операционную систему компании OS/2, а поддержка была добавлена ​​в Linux, начиная с ядер 2.4.20 и 2.5.6 после того, как он был преобразован в открытый исходный код. В настоящее время JFS в основном используется на корпоративных серверах IBM, а также является хорошим выбором для систем с мультизагрузкой Linux и OS/2.

XFS была разработана в середине 1990-х годов компанией Silicon Graphics (SGI) для своих 64-разрядных серверов IRIX UNIX. Эти серверы были разработаны для расширенной обработки графики, поэтому они способны обрабатывать файлы огромных размеров. Компания также преобразовала XFS в систему с открытым исходным кодом, после чего она также была адаптирована для Linux. Поскольку это 64-битная файловая система, XFS имеет ограничения по размеру в миллионы терабайт (в отличие от все еще щедрого предела в 4 ТБ для ext2). Поддержка была добавлена ​​в ядре 2.5.36.

Новой журналируемой файловой системой для Linux является ext4, разработка которой сейчас находится на завершающей стадии. Ext4 разработан с учетом быстро приближающейся эпохи терабайтных (1024 гигабайт) жестких дисков и поддерживает хранение до 1024 петабайт (1024 терабайт) на том.

Создано 13 апреля 2007 г.
Авторские права © 2007 The Linux Information Project. Все права защищены.

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

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

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

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

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

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

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

Ведение журнала экономит много времени при извлечении файлов из хранилища из-за выделения непрерывной памяти.

Определения

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

Тебибайты (TiB): все мы знаем, сколько составляет гигабайт. Тебибайт (ТиБ) равен 1024 (= 2 10 ) гигабайтам. ТиБ — это одна из единиц по умолчанию для выражения больших значений в файловом хранилище. Кроме того, 1 ТиБ = 1,09951 терабайт (ТБ).

Пебибайт (ПиБ): пебибайт (ПиБ) равен 1024 ТиБ или примерно миллиону гигабайт — действительно очень большое значение.

Кластеры: кластеры данных — это наименьшая единица дискового пространства, которую можно использовать для хранения файла. Он может варьироваться от 512 байт для одного сектора до 64 КБ для 128 секторов.

1. NTFS

Файловая система новой технологии (NTFS) — это система ведения журналов Microsoft по умолчанию для Windows и Windows Server. Он использует файлы журналов и информацию о контрольных точках для восстановления стабильных значений файловой системы после перезапуска.

NTFS поддерживает большие объемы данных: кластер размером 4 КБ может вместить 16 ТиБ данных. Для размера кластера 64 КБ (максимум) это означает 256 ТиБ данных с 256 ТиБ в качестве максимального размера файла.

В настоящее время NTFS устраняет любые повреждения файлов в режиме онлайн с помощью так называемой «самовосстанавливающейся NTFS». Пользователи Windows 10, возможно, помнят время простоя из-за Chkdsk, который использовался в старых версиях Windows. В последнем самовосстанавливающемся обновлении NTFS проблема была решена в режиме онлайн, без простоев.

Также читайте: FAT32, exFAT и NTFS: в чем разница?

2. Доп

Расширенная файловая система (ext) с самого начала была системой журналирования в Linux. Он был вдохновлен файловой системой Unix (UFS) и претерпел еще три итерации с момента своего появления в начале 90-х годов.

  • ext2: изначально использовавшийся в Debian и Red Hat Linux, ext2 до сих пор используется на флэш-носителях, таких как SD-карты и USB-накопители. Он может вместить от 2 до 32 ТиБ данных с максимальным размером кластера 8 КБ.
  • ext3: третья расширенная файловая система ext3 использовалась в Linux, BSD и ReactOS. Ограничения по размеру аналогичны ext2.
  • ext4: последняя версия расширенной файловой системы, она используется файловым хранилищем Google, BSD, PowerPC и большинством последних дистрибутивов Linux. Ограничения по размеру равны 1024 ПиБ или около миллиона ТиБ. Максимальный размер кластера — 64 КБ.

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

3. APFS

Файловая система Apple (APFS) используется в macOS High Sierra, iOS 10.3 и более поздних версиях, а также в некоторых других системах. Он поддерживает до 8000 ПиБ (263 байта), что примерно в восемь раз больше, чем у ext4.

Основных возможностей APFS много: они включают создание «моментальных снимков», которые похожи на фотокопии системы в определенной точке. Как и NTFS, он использует контрольные суммы для обеспечения целостности данных и защищает от сбоев системы, используя подход, называемый «копирование при записи». APFS использует полное шифрование диска.

Заключение

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

Помимо обсуждаемых здесь, существует множество журналируемых файловых систем. Oracle, VMware, BSD, Cisco, Solaris и многие другие имеют свои собственные блоки журнала.

Даже в википедии мало информации. Помимо NTFS, какие другие файловые системы (в Windows / Linux) поддерживают ведение журнала и как это дает прирост производительности?

4 ответа 4

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

В разделе «Возможности» Википедии приводится сравнение файловых систем, которые ведутся в журнале.

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

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

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

Например, если вы хотите переместить файл с одного диска на другой, процедура будет выглядеть примерно так:

  • Физически скопировать старый файл в новое место
  • Обновить запись каталога на новом диске
  • Удалить запись каталога со старого диска
  • Свободное место на старом диске

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

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

В журналируемой файловой системе используется та же основная процедура с несколькими дополнительными шагами. Что-то вроде:

  • Запись в журнале: перемещение файла из точки А в точку Б
    • Физически скопировать старый файл в новое место
    • Обновить запись каталога на новом диске
    • Удалить запись каталога со старого диска
    • Свободное место на старом диске

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

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

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

    Читайте также: