--- authors: - author: 'Manolis Kiagias' email: manolis@FreeBSD.org - author: 'Vladlen Popolitov' email: vladlen@FreeBSD.org description: 'Настройка журналирования UFS для настольного компьютера' tags: ["UFS", "Journaling" , "Desktop", "FreeBSD"] title: 'Настройка журналирования UFS для настольного компьютера' trademarks: ["freebsd", "general"] --- = Настройка журналирования UFS для настольного компьютера :doctype: article :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/gjournal-desktop/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Аннотация Журналируемая файловая система использует журнал для записи обновлений файловой системы и обеспечивает целостность данных в случае сбоя системы или отключения питания. Несмотря на то, что несохранённые изменения в файлах всё ещё могут быть утеряны, журналирование значительно снижает риск повреждения файловой системы из-за некорректного завершения работы и существенно сокращает время восстановления. Хотя файловая система UFS, используемая в FreeBSD, не реализует журналирование как встроенную функцию на уровне диска, FreeBSD предоставляет поддержку журналирования через механизмы на уровне файловой системы (Soft Updates с журналированием), а также через фреймворк GEOM (`gjournal`). В этой статье описываются доступные механизмы журналирования UFS и объясняется их целесообразное использование в современных системах FreeBSD. _Содержание было проверено и обновлено для версий FreeBSD с 13 по 15_. ''' toc::[] [[introduction]] == Введение Серверное оборудование обычно хорошо защищено от потери питания. Настольный компьютер часто подвержен неожиданным пропаданиям питания, случайным нажатиям кнопки Reset и другим происшествиям (часто связанным с неосторожностью пользователей), которые могут привести к непредвиденным выключениям и оставить файловую систему в несогласованном состоянии. Традиционно это требовало запуска `fsdk`, что на больших файловых системах требует значительного времени. В очень редких случаях повреждения файловой системы достигают того уровня, при котором становится необходимым вмешательство пользователя и данные могут быть утерянными. FreeBSD предоставляет два различных механизма журналирования для файловой системы UFS: * Журналирование с Soft Updates * Журналирование с командой GEOM `gjournal` Эти механизмы функционируют на различных уровнях системы и обладают разными характеристиками производительности и семантики. [IMPORTANT] ==== Для большинства современных систем FreeBSD, включая настольные компьютеры и серверы общего назначения, рекомендуется использовать *Soft Updates с журналированием*. GEOM журналирование — это устаревший и специализированный механизм, и его следует использовать только тогда, когда требуются его специфические семантики. ==== В этой статье объясняются оба механизма, их различия и правильное современное использование. Прочтите эту главу, чтобы узнать: * Доступные механизмы журналирования для файловой системы UFS в FreeBSD и их различия. * Когда использовать журналирование на уровне файловой системы с Soft Updates и когда может быть уместно журналирование GEOM. * Как включить или отключить журналирование Soft Updates на существующих файловых системах UFS. * Как настроить журналирование GEOM на новых или существующих разделах, включая необходимую поддержку ядра и вопросы определения размера журнала. * Какие изменения конфигурации необходимы для монтирования журналируемых файловых систем и как журналирование влияет на поведение системы. * Как диагностировать неполадки и разрешать проблемы, связанные с журналированием файловой системы UFS. Перед прочтением этой статьи вам необходимо: * Понимать базовые концепции таких операционных систем, как UNIX(R) и FreeBSD. * Быть знакомым с процедурой установки FreeBSD, используя bsdinstall. * Иметь базовые знания о разбиении дисков и файловых системах, включая такие инструменты, как gpart(8), newfs(8) и mount(8). [WARNING] ==== Некоторые процедуры, описанные в данной статье, включают изменение конфигурации файловой системы или диска и могут потребовать размонтирования файловых систем или изменения метаданных на диске. Перед внесением подобных изменений в работающей системе убедитесь, что доступны надежные _резервные копии_ всех важных данных. Включение журналирования Soft Updates на уровне файловой системы обычно безопасно и не требует переразбивки диска. Однако настройка журналирования GEOM включает низкоуровневые операции с диском и должна выполняться только опытными администраторами, полностью понимающими последствия. ==== [[understanding-journaling]] == Реализация журналирования в FreeBSD === Soft Updates с журналированием (рекомендуется) Soft Updates — это механизм обеспечения согласованности UFS по умолчанию в FreeBSD. В сочетании с журналированием он обеспечивает *журналирование метаданных* в самой файловой системе. Преимущества Soft Updates с журналированием включают: * Очень быстрое восстановление после сбоя (обычно за секунды) * Обычная семантика `sync(2)` и `fsync(2)` * Никаких дополнительных разделов или слоев GEOM * Простая настройка и обслуживание Из `tunefs(8)`: ____ Включение журналирования сокращает время, затрачиваемое fsck_ffs(8) на очистку файловой системы после сбоя, с нескольких минут или часов до нескольких секунд. ____ Этот механизм подходит практически для всех систем на основе UFS и является рекомендуемым по умолчанию. === Журналирование с командой GEOM `gjournal` GEOM журналирование работает на блочном уровне, ниже файловой системы. Оно журналирует все записи блоков, включая *как метаданные, так и данные файлов*. Ключевые характеристики журналирования GEOM: * Реализовано как класс GEOM (`geom_journal`) * Журналирует весь блочный ввод-вывод, а не только метаданные * Требует явного согласования от UFS с использованием флага `-J` * Отключает Soft Updates * Изменяет семантику `sync(2)` и `fsync(2)` [WARNING] ==== На файловых системах с журналированием GEOM, `sync(2)` и `fsync(2)` не гарантируют, что данные были записаны на постоянное хранилище. Для обеспечения сохранности необходимо использовать `gjournal sync`. ==== Из-за этих различий журналирование GEOM не рекомендуется для общего использования на настольных компьютерах или серверах. == Выбор подходящего метода журналирования В следующей таблице приведены рекомендуемые варианты использования: [cols="1,1", options="header"] |=== | Вариант использования | Рекомендуемый механизм | Настольная или портативная система | Журналирование с Soft Updates | Универсальный сервер | Журналирование с Soft Updates | Устаревшие системы UFS | Журналирование с Soft Updates | Требования к журналированию, не зависящие от файловой системы | Журналирование GEOM | Специализированное журналирование на уровне блоков | Журналирование GEOM |=== == Использование Soft Updates с журналированием Soft Updates с журналированием обеспечивают журналирование на уровне файловой системы для UFS. Этот механизм сохраняет целостность файловой системы, одновременно сохраняя оптимизации выделения и упорядочивания, характерные для Soft Updates. В отличие от журналирования GEOM, отдельное журналирующее устройство или раздел не требуется. === Обзор Soft Updates с журналированием записывают изменения метаданных файловой системы в журнал, хранящийся внутри самой файловой системы, реализованный как скрытый файл с именем [.filename]#.sujournal# в корне файловой системы. В случае сбоя или отключения питания ожидающие операции с метаданными воспроизводятся из журнала, что позволяет быстро смонтировать файловую систему без полной проверки согласованности. Эта форма журналирования применяется только к метаданным файловой системы. Целостность данных файлов остается ответственностью приложений. === Включение журналирования на существующей файловой системе Файловая система должна быть размонтирована или смонтирована в режиме только для чтения перед изменением настроек журналирования. [source, shell] ---- # umount /usr # tunefs -n enable -j enable /dev/ada0p2 # mount /usr ---- Дополнительная настройка не требуется. Можно использовать стандартные параметры монтирования. === Хранение журналов и их размер Размер журнала по умолчанию выбирается автоматически при включении ведения журнала. В большинстве случаев размер по умолчанию достаточен и не требует корректировки. При необходимости размер журнала в байтах может быть явно указан с помощью опции `-S` для `tunefs(8)`: [source, shell] ---- # tunefs -S 64000000 /dev/ada0p2 ---- Настройка размера журнала редко требуется и должна рассматриваться только для файловых систем с необычно высокой частотой обновления метаданных. === Проверка Soft Updates с журналированием Статус журналирования файловой системы UFS с использованием Soft Updates можно проверить с помощью `tunefs(8)` или `dumpfs(8)`. Чтобы отобразить текущие настройки файловой системы, выполните: [source, shell] ---- # tunefs -p /dev/ada0p2 | grep -i journal tunefs: soft updates journaling: (-j) enabled tunefs: gjournal: (-J) disabled ---- Ищите следующие индикаторы в выводе: * Soft Updates включены * Soft Updates с журналированием включены Или для проверки суперблока файловой системы можно использовать `dumpfs(8)`: [source, shell] ---- English type: delimited block - 4 # dumpfs /dev/ada0p2 | grep -i journal flags soft-updates+journal ---- Эти команды предназначены только для чтения и не изменяют состояние файловой системы. === Проверка и обслуживание файловой системы Хотя журналирование значительно сокращает время восстановления после сбоя, оно не устраняет необходимость периодических полных проверок файловой системы. * Журналирование гарантирует целостность, а не корректность * Ошибки носителя не исправляются журналированием * Периодическая проверка `fsck` все еще должна быть запланирована * Фоновый `fsck` может использоваться на работающих файловых системах == Использование журналирования GEOM (Продвинутый уровень) [WARNING] ==== Данный раздел предназначен для опытных пользователей, которые понимают последствия журналирования на уровне блоков и изменения семантики синхронизации. ==== === Обзор Возможность журналирования обеспечивается загрузкой модуля [.filename]#geom_journal.ko# в ядро (или сборкой собственного ядра с активированием соответствующих опций) и использованием команды `gjournal` для конфигурирования файловой системы. В общем, вы предпочтете журналировать файловые системы большого размера, к примеру - [.filename]#/usr#. Однако, вам придется зарезервировать некоторое количество свободного места (см. следующий раздел). Журналирование GEOM реализовано модулем ядра `geom_journal` и настраивается с помощью утилиты `gjournal(8)`. Оно обеспечивает журналирование на уровне блоков ниже слоя файловой системы и требует явной поддержки со стороны UFS. При использовании журналирования GEOM требуется некоторое дисковое пространство для хранения самого журнала. Провайдер, содержащий данные файловой системы, называется _провайдером данных_, а провайдер, хранящий журнал, называется _провайдером журнала_. При журналировании существующей (непустой) файловой системы провайдеры данных и журнала должны быть раздельными. При журналировании новой, пустой файловой системы, один провайдер может использоваться для хранения как данных, так и информации журнала. В обоих случаях `gjournal(8)` объединяет провайдеры данных и журнала для создания нового журналируемого провайдера, который затем монтируется файловой системой. Например: * Файловая система `/usr` расположена на `/dev/ada0p2` и уже содержит данные. * Свободное дисковое пространство выделено в отдельном разделе, `/dev/ada0p4`, для хранения журнала. * После настройки журналирования GEOM создается новый провайдер `/dev/ada0p2.journal`. Этот журналируемый провайдер объединяет `/dev/ada0p2` в качестве провайдера данных и `/dev/ada0p4` в качестве провайдера журнала и используется для всех последующих операций файловой системы. Объем дискового пространства, необходимого для журнала, в первую очередь зависит от интенсивности записи в файловую систему, а не от размера поставщика данных. Системам с постоянной или импульсной активностью записи требуются журналы большего размера, чтобы избежать чрезмерного переключения журналов или ограничения записи. Из справочной страницы `gjournal(8)`: * Размер журнала по умолчанию составляет 1 ГБ. * Рекомендуемый минимальный размер журнала составляет удвоенный объем установленной оперативной памяти. * Размер журнала должен выбираться на основе ожидаемой нагрузки записи, а не размера файловой системы. Недостаточный размер журнала может привести к снижению производительности или вынужденным переключениям журнала при высокой нагрузке на запись. Для получения дополнительной информации о журналировании, пожалуйста, прочитайте страницу справочника, посвященную man:gjournal[8]. [[reserve-space]] === Действия, необходимые во время установки FreeBSD В этом разделе описывается необязательная подготовка во время установки для систем, настроенных на использование журналирования GEOM. Цель — зарезервировать дисковое пространство для журнальных провайдеров, которые впоследствии будут связаны с файловыми системами `/usr` и `/var`. ==== Выделение места под журналирование На типичной системе с одним диском операционная система, установленное программное обеспечение и пользовательские данные находятся на одном устройстве. Стандартное автоматическое разбиение, выполняемое установщиком FreeBSD, выделяет большую часть доступного пространства под `/usr`, с меньшими разделами для `/var` и других точек монтирования. По умолчанию установщик выделяет всё доступное дисковое пространство для файловых систем и не оставляет неиспользуемого места. Если планируется использование журналирования GEOM для существующих (непустых) файловых систем, необходимо зарезервировать дополнительное дисковое пространство для размещения журнальных провайдеров. Каждая файловая система, которая будет журналироваться, требует собственного журнального провайдера. Поскольку `/usr` обычно занимает наибольшую часть диска, это наиболее практичный раздел для небольшого уменьшения, чтобы освободить место для журналируемых провайдеров. В нашем примере журналирование GEOM планируется как для `/usr`, так и для `/var`. ==== Стратегия разбиения на разделы Во время установки используйте режим ручного разбиения, предоставляемый установщиком. Создайте любую поддерживаемую файловую систему для `/`, а также стандартные разделы UFS для `/usr` и `/var`, но уменьшите размер `/usr`, чтобы оставить достаточно нераспределенного пространства в конце диска. Из оставшегося нераспределенного пространства создайте два дополнительных раздела, которые будут использоваться исключительно в качестве журнальных провайдеров: * Один раздел для журнала `/usr` * Один раздел для журнала `/var` Эти разделы не должны иметь назначенных точек монтирования и не должны использоваться для подкачки. Они останутся неиспользованными до тех пор, пока не будут явно связаны с соответствующими поставщиками данных с помощью `gjournal(8)` после установки. Типичная схема может выглядеть следующим образом: .Разделы, Зарезервированные для Журналирования GEOM [cols="1,1,2", options="header"] |=== | Поставщик | Предназначение | Заметки |/dev/ada0p2 |/var |Файловая система UFS (поставщик данных) |/dev/ada0p3 |/usr |Файловая система UFS (поставщик данных) |/dev/ada0p4 |Журнал для /var |Неформатированный, неиспользуемый раздел |/dev/ada0p5 |Журнал для /usr |Неформатированный, неиспользуемый раздел |=== Точные названия устройств могут различаться в зависимости от структуры диска и схемы разделов. Настоятельно рекомендуется записать имена провайдеров во время установки, так как они потребуются при настройке журнала. ==== Соображения по размеру журнала Размер журнала зависит от ожидаемой нагрузки на запись, а не от размера файловой системы. Для систем общего назначения обычно достаточно журналов размером 1–2 ГБ. Системам с постоянной или импульсной активностью записи могут потребоваться журналы большего размера. Выделяйте пространство под журнал экономно во время установки, так как изменение размера разделов позже может потребовать дополнительного времени простоя. ==== Завершение инсталляции После резервирования необходимых разделов завершите установку FreeBSD в обычном режиме. Рекомендуется отложить установку стороннего программного обеспечения и дополнительную настройку системы до полной настройки журналирования GEOM. На этом этапе система загрузится с использованием стандартных файловых систем UFS. Зарезервированные журнальные разделы останутся неиспользованными до тех пор, пока журналирование не будет явно включено. [[first-boot]] ==== Первая загрузка после установки После первого успешного запуска немедленные изменения конфигурации не требуются. Следует убедиться, что система загружается и работает нормально, прежде чем продолжить. После того, как подтверждено, что базовая система работоспособна, следующие шаги включают: * Загрузка или включение поддержки журналирования GEOM * Связывание журнальных провайдеров с соответствующими провайдерами данных * Обновление `/etc/fstab` для монтирования журналируемых устройств Эти шаги описаны в следующем разделе. [[configure-journal]] === Настройка журналирования [[running-gjournal]] ==== Включение журналирования GEOM в существующих файловых системах В этом разделе описывается, как включить журналирование GEOM для файловых систем `/usr` и `/var`, используя разделы, подготовленные в процессе установки. После резервирования необходимых журнальных провайдеров можно настроить журналирование GEOM. Поскольку файловые системы, подлежащие журналированию, не должны быть смонтированы, систему необходимо переключить в однопользовательский режим. Залогиньтесь `root` и введите: [source, shell] .... # shutdown now .... Нажмите kbd:[Enter] для получения приглашения командного интерпретатора в режиме root. Нам необходимо будет размонтировать разделы, которые подлежат журналированию, в нашем примере это [.filename]#/usr# и [.filename]#/var#: [source, shell] .... # umount /usr /var .... Загрузите модуль ядра GEOM journaling: [source, shell] .... # gjournal load .... Далее, свяжите каждого поставщика данных с соответствующим поставщиком журналов. Используйте свои заметки, чтобы определить, какой раздел будет использоваться для каждого журнала. В этом примере: * `/usr` находится на `/dev/ada0p3`, а его журнальный провайдер — `/dev/ada0p5` * `/var` находится на `/dev/ada0p2`, а его журнальный провайдер — `/dev/ada0p4` Создайте журналируемые провайдеры с помощью `gjournal(8)`: [source, shell] .... # gjournal label ada0p3 ada0p5 GEOM_JOURNAL: Journal 2948326772: ada0p5 contains journal. GEOM_JOURNAL: Journal 2948326772: ada0p3 contains data. GEOM_JOURNAL: Journal ada0p3 clean. # gjournal label ada0p2 ada0p4 GEOM_JOURNAL: Journal 3193218002: ada0p4 contains journal. GEOM_JOURNAL: Journal 3193218002: ada0p2 contains data. GEOM_JOURNAL: Journal ada0p2 clean. .... [NOTE] ==== Если `gjournal` сообщает, что последний сектор провайдера используется, команда завершится неудачей. На свежесозданных или неиспользуемых разделах безопасно повторить операцию с флагом `-f` для принудительной инициализации: [source, shell] .... # gjournal label -f /dev/ada0p2 /dev/ada0p4 .... ==== После маркировки создаются два новых журналируемых провайдера: * `/dev/ada0p3.journal` для `/usr` * `/dev/ada0p2.journal` для `/var` Эти устройства заменят исходные источники данных при монтировании файловых систем. Перед монтированием необходимо установить для них флаг журнала и снять флаг Soft Updates: [source, shell] .... # tunefs -J enable -n disable -j disable /dev/ada0p3.journal tunefs: soft updates journaling cleared but soft updates still set tunefs: remove .sujournal to reclaim space tunefs: gjournal set tunefs: soft updates cleared # tunefs -J enable -n disable -j disable /dev/ada0p2.journal tunefs: soft updates journaling cleared but soft updates still set tunefs: remove .sujournal to reclaim space tunefs: gjournal set tunefs: soft updates cleared .... Теперь, смонтируйте новые устройства в соответствующие места файловой системы (обратите внимание на то, что мы можем использовать опцию монтирования `async`) и удалите [.filename]#.sujournal#, чтобы освободить место на диске: [source, shell] .... # mount -o async /dev/ada0p2.journal /var # rm /var/.sujournal # mount -o async /dev/ada0p3.journal /usr # rm /usr/.sujournal .... Откройте [.filename]#/etc/fstab# и исправьте записи для следующих файловых систем: [.filename]#/usr# и [.filename]#/var#: [.programlisting] .... /dev/ada0p3.journal /usr ufs rw,async 2 2 /dev/ada0p2.journal /var ufs rw,async 2 2 .... [WARNING] ==== Проверьте корректность всех указанных параметров - в противном случае после перезагрузки возможны проблемы со стандартным запуском системы! ==== Наконец, внесите изменения в [.filename]#/boot/loader.conf#, добавив строку для автоматической загрузки модуля man:gjournal[8] при каждом старте системы: [.programlisting] .... geom_journal_load="YES" .... Поздравляем! Ваша система теперь настроена для журналирования. Вы можете ввести команду `exit` для возврата в многопользовательский режим или перезагрузить систему для проверки конфигурации (рекомендуется). [source, shell] .... # shutdown -r now .... Во время перезагрузки вы увидите сообщение следующего вида: [source, shell] .... # dmesg | grep GEOM_JOURNAL GEOM_JOURNAL: Journal 2948326772: ada0p4 contains journal. GEOM_JOURNAL: Journal 3193218002: ada0p5 contains journal. GEOM_JOURNAL: Journal 2948326772: ada0p2 contains data. GEOM_JOURNAL: Journal ada0p2 clean. GEOM_JOURNAL: Journal 3193218002: ada0p3 contains data. GEOM_JOURNAL: Journal ada0p3 clean. .... После некорректного завершения работы сообщения будут немного отличаться, например: [source, shell] .... GEOM_JOURNAL: Journal ada0p2 consistent. .... Обычно это означает, что man:gjournal[8] использовал информацию из журнала для приведения файловой системы в согласованное состояние. [[gjournal-new]] ==== Включение журналирования GEOM на вновь созданных разделах Процедура, описанная ранее, необходима при включении журналирования GEOM на файловых системах, которые уже содержат данные. При журналировании только что созданного, пустого раздела процесс проще, так как и данные, и журнальные провайдеры могут находиться в одном разделе. Такой подход обычно используется для новых дисков или недавно выделенных разделов, которые еще не были отформатированы под файловую систему. Процедура, описанная выше, необходима для подключения журналирования разделов, содержащих данные. Журналирование пустых разделов немного проще, ввиду того, что поставщик данных и поставщик журнала могут быть размещены на одном и том же разделе. Например, предположим, что был установлен новый жёсткий диск и был создан новый раздел [.filename]#/dev/ada1p1#. Создание журнала не сложнее набора: [source, shell] .... # gjournal label /dev/ada1p1 .... Размер журнала - 1 Гб по умолчанию. Однако, вы можете изменить это значение используя ключ `-s`. Значение можно задавать в байтах, в килобайтах, мегабайтах или гигабайтах (используя суффикс `K`, `M` или `G`). Имейте ввиду, что команда `gjournal` не позволит вам создать журнал недопустимо малого размера. К примеру, чтобы создать журнал размером в 2Гб, можно использовать следующую команду: [source, shell] .... # gjournal label -s 2G /dev/ada1p1 .... Далее, вы можете создать файловую систему UFS на новом разделе, разрешить журналирование, используя `newfs(8)` на устройстве `.journal`, и запретить Soft Updates, используя `tunefs(8)`: [source, shell] .... # newfs -J /dev/ada1p1.journal # tunefs -n disable -j disable /dev/ada1p1.journal .... После создания файловой системы её можно смонтировать обычным способом. Например, чтобы смонтировать её в `/data`: [source, shell] .... # mount /dev/ada1p1.journal /data .... Чтобы обеспечить автоматическое монтирование файловой системы при загрузке, добавьте запись в [.filename]#/etc/fstab#: [.programlisting] .... /dev/ada1p1.journal /data ufs rw,async 2 2 .... ===== Заметки по использованию При использовании одного провайдера для хранения данных и журналов: * Раздел должен быть пустым перед выполнением `gjournal label` * Журнальное пространство выделяется внутри раздела диска * Размер файловой системы будет уменьшен на размер журнала [[configure-kernel]] === Встраивание журналирования в собственное ядро Если вы не желаете загружать `geom_journal` как модуль, то можно встроить его функции прямо в ваше специализированное ядро. Редактируя конфигурационный файл ядра, убедитесь, что в нём находятся следующие две строки: [.programlisting] .... options UFS_GJOURNAL <1> options GEOM_JOURNAL <2> .... <.> Обратите внимание — это уже есть в GENERIC <.> Вам надо добавить эту опцию Соберите и установите новое ядро следуя указаниям extref:{handbook}kernelconfig[Руководства FreeBSD., kernelconfig] И не забудьте удалить соответствующую строку загрузки модуля ("load") из [.filename]#/boot/loader.conf# (если на предыдущем этапе она была туда внесена). === Проверка GEOM журналирования Статус журналирования GEOM можно уточнить, проверив активные провайдеры GEOM. Чтобы вывести список всех активных устройств журналирования GEOM, выполните: [source, shell] ---- # gjournal list ---- Или для просмотра сводки состояния журнала: [source, shell] ---- # gjournal status ---- Журналируемые файловые системы обозначаются именами устройств, оканчивающимися на `.journal`. Наличие этих провайдеров указывает на активность журналирования GEOM. Дополнительную информацию о цепочке устройств GEOM можно получить с помощью: [source, shell] ---- # geom -t ---- Или для проверки суперблока файловой системы можно использовать `dumpfs(8)`: [source, shell] ---- # dumpfs /dev/ada0p2.journal | grep -i journal flags gjournal ---- [[troubleshooting-journaling]] [[troubleshooting-gjournal]] == Устранение неполадок с журналированием Этот раздел содержит часто задаваемые вопросы касательно неполадок, связанных с журналированием. === Я получаю паники ядра во время высокой дисковой активности. Это связано с журналированием GEOM? На современных системах FreeBSD аварийные остановки системы, вызванные исключительно недостаточным размером журнала GEOM, встречаются редко. При продолжительных или интенсивных всплесках нагрузки на запись, недостаточный размер журнала обычно приводит к регулированию записи или временным задержкам ввода-вывода во время сброса журнала на устройство хранения данных. Аварийная остановка системы может возникнуть лишь в исключительных случаях, обычно в сочетании с дополнительными проблемами, такими как ошибки ввода-вывода или исчерпание ресурсов, когда продолжение работы может угрожать целостности файловой системы. Если наблюдаются аварийные остановки при интенсивной активности записи, рекомендуется увеличить размер журнала для затронутой файловой системы. === Я допустил некоторые ошибки во время конфигурирования, теперь система не загружается. Можно это как-нибудь исправить? Вы либо забыли внести запись (опечатались) в [.filename]#/boot/loader.conf#, либо есть ошибки в файле [.filename]#/etc/fstab#. Это легко исправить. Во время загрузки системы, когда процесс загрузки остановится и появится запрос входа в однопользовательский режим (например, после сбоя монтирования или ошибки `fsck`), нажмите kbd:[Enter], чтобы получить приглашение командного интерпретатора в однопользовательском режиме. Потом, проверьте возможные варианты: [source, shell] .... # cat /boot/loader.conf .... Убедитесь, что следующая строка существует и написана правильно: [.programlisting] .... geom_journal_load="YES" .... Если отсутствует запись `geom_journal_load`, или она содержит ошибки, журналируемые устройства не создадутся. Загрузите модуль вручную, примонтируйте все разделы и переходите в многопользовательский режим (продолжайте загрузку): [source, shell] .... # gjournal load GEOM_JOURNAL: Journal 2948326772: ada0p4 contains journal. GEOM_JOURNAL: Journal 3193218002: ada0p5 contains journal. GEOM_JOURNAL: Journal 2948326772: ada0p2 contains data. GEOM_JOURNAL: Journal ada0p2 clean. GEOM_JOURNAL: Journal 3193218002: ada0p3 contains data. GEOM_JOURNAL: Journal ada0p3 clean. # mount -a # exit (boot continues) .... Если же запись о `geom_journal_load` верна, то проверьте [.filename]#/etc/fstab#. Вероятней всего, что вы обнаружите опечатку или отсутствие необходимой записи. В этом случае смонтируйте вручную оставшиеся разделы и продолжите загрузку в многопользовательский режим. === Возможно ли отказаться от журналирования и вернуться к моей привычной файловой системе с механизмом Soft Updates? Несомненно. Используйте приведённую ниже последовательность действий, которая обращает изменения. Разделы, созданные для поставщиков журналов, могут позже быть использованы для других целей. Залогиньтесь `root` и переведите систему в однопользовательский режим: [source, shell] .... # shutdown now .... Размонтируйте журналируемые разделы: [source, shell] .... # umount /usr /var .... Синхронизируйте журналы: [source, shell] .... # gjournal sync .... Остановите поставщиков журналов: [source, shell] .... # gjournal stop ada0p2.journal # gjournal stop ada0p3.journal .... Следующий шаг должен быть выполнен с выгруженным модулем ядра gjournal. Если следующая команда завершится неудачей: [source, shell] ... # gjournal unload ... Убедитесь, что следующая строка присутствует в [.filename]#/boot/loader.conf# и написана правильно: [.programlisting] .... geom_journal_load="NO" .... Перезагрузите ваш компьютер без модуля ядра gjournal: [source, shell] .... # shutdown -r now .... Войдите в систему в однопользовательском режиме еще раз. Удалите метаданные журналирования со всех задействованных устройств: [source, shell] .... # gjournal clear ada0p2 # gjournal clear ada0p3 # gjournal clear ada0p4 # gjournal clear ada0p5 .... Снимите флаг журналирования и установите флаги механизма Soft Updates: [source, shell] .... # tunefs -J disable -n enable -j enable ada0p2 tunefs: soft updates journaling set tunefs: gjournal cleared tunefs: soft updates set # tunefs -J disable -n enable -j enable ada0p3 tunefs: soft updates journaling set tunefs: gjournal cleared tunefs: soft updates set .... Смонтируйте вручную старые (первоначальные) устройства: [source, shell] .... # mount -o rw /dev/ada0p2 /var # mount -o rw /dev/ada0p3 /usr .... Откройте файл [.filename]#/etc/fstab# и приведите его к изначальному виду: [.programlisting] .... /dev/ada0p2 /usr ufs rw 2 2 /dev/ada0p3 /var ufs rw 2 2 .... И напоследок, удалите строку, загружающую модуль `geom_journal`, из файла [.filename]#/boot/loader.conf# (или включите его опять, если он по прежнему требуется для других разделов диска), и перезагрузите операционную систему. === Как временно загрузиться без журналирования GEOM? Чтобы загрузить систему без журналирования GEOM, предотвратите загрузку модуля журнала во время запуска. Закомментируйте или удалите соответствующую строку из [.filename]#/boot/loader.conf# и перезагрузитесь: [.programlisting] .... geom_journal_load="YES" .... После загрузки без журналирования GEOM, журналируемые устройства (`*.journal`) не будут созданы. Файловые системы должны быть смонтированы с использованием их исходных (не журналируемых) провайдеров или вручную по мере необходимости для восстановления или обслуживания. Этот метод не изменяет метаданные журнала на диске и может безопасно использоваться для устранения неполадок. === Можно ли изменить размер журнала GEOM после его создания? Нет. Журнал GEOM не может быть изменен в размере на месте после его создания. Размер журнала фиксируется в момент выполнения `gjournal label` . Чтобы изменить размер журнала, необходимо удалить журналирование GEOM и переконфигурировать его с новым провайдером журнала желаемого размера. Для файловых систем, содержащих данные, это требует размонтирования файловой системы и воссоздания журнала с использованием провайдеров соответствующего размера, как описано ранее в этой статье. Планируйте размеры журналов консервативно, чтобы они соответствовали пиковой активности записи, так как изменение размера требует повторной инициализации конфигурации журнала. === Что происходит после некорректного завершения работы или сбоя питания? После некорректного завершения работы или сбоя питания, журналирование GEOM и Soft Updates с журналированием воспроизводят ожидающие записи журнала во время следующей загрузки, чтобы вернуть файловую систему в согласованное состояние. Если восстановление журнала завершается успешно, файловая система монтируется в обычном режиме, и полная проверка файловой системы не требуется. Восстановление журнала обычно занимает всего несколько секунд и зависит от объема недавней активности записи, а не от размера файловой системы. Полная проверка файловой системы может потребоваться в редких случаях, например, при обнаружении ошибок в устройстве хранения или несоответствии самого журнала. === Как взаимодействует журналирование GEOM с fsck? Журналирование GEOM и Soft Updates с журналированием взаимодействуют с `fsck_ffs(8)` различными способами, отражая их разные уровни интеграции в стеке хранения FreeBSD. Для журналирования GEOM восстановление после сбоя выполняется самой структурой GEOM. Во время запуска системы класс `geom_journal` обнаруживает метаданные журнала и воспроизводит все ожидающие записи журнала, пока провайдер обрабатывается GEOM, до того как журналируемое устройство станет видимым для более высоких уровней системы. Если воспроизведение журнала завершается успешно, файловая система возвращается в согласованное состояние, и суперблок UFS обновляется, чтобы указать, что проверка файловой системы не требуется. Когда позже во время загрузки вызывается `fsck_ffs(8)`, он считывает это состояние из суперблока и пропускает проверку файловой системы. Для Soft Updates с журналированием восстановление инициируется самим `fsck_ffs(8)`. Во время проверки файловой системы при загрузке, `fsck_ffs(8)` обнаруживает, что файловая система поддерживает Soft Updates с журналированием, и запускает логику воспроизведения журнала. Если воспроизведение журнала сообщает, что файловая система непротиворечива, `fsck_ffs(8)` завершается досрочно без выполнения полной проверки. Если воспроизведение журнала не может быть успешно завершено, выполняется традиционная проверка файловой системы. В результате, путь восстановления во время загрузки системы зависит от используемого механизма журналирования, что иллюстрируется следующей последовательностью загрузки: ---- Загрузчик системы | v Инициализация ядра | v Фреймворк GEOM framework (обнаружение поставщиков - tasting) | +--> Журналирование GEOM (gjournal) | - Выполнение записи на диск из журнала выполняется на этом этапе | - Согласованность файловой системы восстановлена | - Суперблок обновлен | v Фаза проверки файловой системы (fsck_ffs) | +--> Журналирование с Soft Updates | - Выполнение записи на диск из журнала, инициированное командой fsck | - fsck сразу выходит, если файловая система в согласованном состоянии | v Монтирование файловой системы | v Обычная работа системы ---- `fsck_ffs(8)` всё ещё используется, когда восстановление журнала не может быть завершено, при обнаружении ошибок базового хранилища или во время периодических ручных или запланированных проверок файловой системы. Журналирование GEOM сокращает время восстановления после сбоев, но не заменяет `fsck_ffs(8)` полностью. === Почему команда `gjournal clear` сообщает "Операция не разрешена" даже в однопользовательском режиме? В GEOM одно и то же базовое хранилище может быть представлено через несколько имён провайдеров одновременно. Например, раздел может быть виден как под своим именем, основанным на диске (например, `vtbd0p7`), так и под меткой GPT (например, `/dev/gpt/labelname`). Это разные провайдеры GEOM, ссылающиеся на одно и то же физическое хранилище. Когда команды `gjournal stop` или `gjournal clear` выполняются на одном имени провайдера, фреймворк GEOM может немедленно снова обнаружить метаданные журнала через другое имя провайдера в процессе распознавание устройства (tasting). В результате журнал автоматически повторно присоединяется, и попытки очистить его метаданные завершаются ошибкой "Операция не разрешена". Технически возможно подавить это поведение, отключив GEOM tasting или предотвратив создание альтернативных имён провайдеров, однако это крайне не рекомендуется. Такие изменения могут негативно повлиять на другие классы GEOM и системные компоненты, которые полагаются на обычное обнаружение провайдеров. По этой причине рекомендованная и безопасная процедура заключается в полной выгрузке модуля `geom_journal` перед удалением журнальных метаданных, как описано ранее в этой статье. При выгруженном модуле не происходит автоматического распознавания, и журнал не может быть повторно подключен, что позволяет команде `gjournal clear` завершиться успешно. === Можно ли использовать журналирование GEOM на корневой файловой системе? Да. Журналирование GEOM может использоваться на корневой файловой системе, но требует дополнительной осторожности при настройке системы. Модуль GEOM journal должен быть загружен на раннем этапе процесса загрузки, чтобы журналируемое корневое устройство было доступно до монтирования корневой файловой системы. Неправильная конфигурация может помешать системе загрузиться в обычном режиме, поэтому данная настройка, как правило, рекомендуется только опытным пользователям, которые полностью понимают последовательность загрузки и процедуры восстановления. По этим причинам журналирование GEOM чаще применяется к некорневым файловым системам, таким как `/usr` и `/var`. === Каковы последствия для производительности при использовании журналирования GEOM? Ведение журнала GEOM вводит дополнительные операции записи ввода-вывода, поскольку все операции записи сначала регистрируются в журнале перед фиксацией на устройстве хранения данных. Это приводит к увеличению задержки записи и более высокому коэффициенту увеличения объёма записи по сравнению с файловыми системами без журналирования. Производительность чтения обычно не страдает. Наиболее заметное влияние на производительность наблюдается при интенсивных нагрузках на запись и зависит от размера журнала, его размещения и скорости базового хранилища. Использование журнала достаточного размера и быстрого хранилища для поставщика журнала минимизирует потери в производительности. === Может ли журналирование GEOM использоваться вместе с другими классами GEOM? Да. GEOM журналирование может быть объединено с другими классами GEOM. При совместном использовании журналирование GEOM обычно работает поверх провайдеров, созданных другими классами GEOM, такими как `gmirror(8)` или `graid3(8)`. Порядок наложения важен и должен соответствовать задокументированным требованиям к слоям задействованных классов GEOM. GEOM журналирование обеспечивает целостность файловой системы на всех уровнях поставщиков, но не заменяет избыточность или обнаружение ошибок, предоставляемые другими классами GEOM. === Можно ли одновременно включить журналирование GEOM и Soft Updates? Нет. GEOM журналирование и Soft Updates не должны быть включены одновременно на одной файловой системе. GEOM журналирование требует исключительного контроля над порядком записи и гарантиями согласованности. Если Soft Updates включены вместе с GEOM журналированием, файловая система может вести себя непредсказуемо, и целостность данных не может быть гарантирована. При использовании журналирования GEOM необходимо отключить Soft Updates на затронутой файловой системе, как описано ранее в этой статье. [[soft-updates]] === В чем разница между Soft Updates и Soft Updates с журналированием? Как Soft Updates, так и Soft Updates with Journaling предназначены для поддержания целостности файловой системы, но используют разные механизмы и ведут себя по-разному после сбоя системы. _Soft Updates_ обеспечивают целостность за счёт тщательного упорядочивания записи метаданных в памяти, так что на диск записываются только безопасные состояния. При сбое любые обновления метаданных, ещё не записанные на диск, просто теряются, оставляя файловую систему в целостном, но, возможно, более старом состоянии. Однако учёт ресурсов может временно быть неточным, и для освобождения неиспользуемых блоков и индексных дескрипторов требуется полный запуск `fsck_ffs(8)`. _Soft Updates с журналированием_ расширяют функциональность _Soft Updates _, добавляя журнал метаданных, хранящийся в файловой системе. Изменения метаданных сначала записываются в журнал и автоматически воспроизводятся при следующей загрузке после некорректного завершения работы. Это позволяет быстро восстановить файловую систему в согласованное состояние, обычно без необходимости полного запуска `fsck_ffs(8)`. Короче говоря, _Soft Updates_ обеспечивают согласованность без журналирования, тогда как _Soft Updates с журналированием_ добавляют быстрое и автоматическое восстановление после сбоев ценой дополнительного дискового пространства и незначительного снижения производительности. [[further-reading]] == Для дальнейшего ознакомления Журналирование - относительно новая функциональная возможность FreeBSD, и она ещё недостаточно документирована. Однако, могут быть полезными следующие источники: * extref:{handbook}geom[Раздел Руководства FreeBSD, geom-gjournal], посвященный журналированию. * http://lists.freebsd.org/pipermail/freebsd-current/2006-June/064043.html[Этот пост] в списке рассылки {freebsd-current}, написанный `{pjd}` - автором man:gjournal[8]. * http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173501.html[Этот пост] от `{ivoras}` в списке рассылки {freebsd-questions}. * https://www.youtube.com/watch?v=_NuhRkiInvA[Journaled Soft-Updates, Dr. Kirk McKusick, BSDCan 2010] на YouTube * https://www.youtube.com/watch?v=xMpmOezBJZo[GEOM - in Infrastructure We Trust, Pawel Jakub Dawidek, AsiaBSDCon 2008] на YouTube * Страницы Справочника man:gjournal[8], man:geom[8] и man:tunefs[8].