Как отключить журналирование файловой системы Ext4 в Linux
Существует большое многообразие файловых систем, созданных в разное время для правильного функционирования в средах различных операционных систем. В Windows — это FAT32, NTFS, exFAT, а в С основными считаются Ext2, Ext3 и Ext4. Журналируемые ФС, как известно, позволяют без участия пользователя осуществлять ведение журнала, в котором хранится список изменений разделов жесткого диска, что определенным образом помогает поддерживать целостность файловой структуры в периоды сбоев ее работы.
Однако, этот функционал в свое время разрабатывался под стандартные жесткие диски (HDD) и именно по отношению к ним он крайне полезен, тогда как для SSD и SD-карт ситуация обратная — журналирование им скорее навредит, ведь мало того, что они имеют ограниченное количество циклов перезаписи, так еще и получается даунгрейд в производительности. Именно поэтому, решив создать на съемном устройстве раздел с файловой системой без ограничений на размер файла (в разумных пределах), следует воспользоваться возможностью отключить журналирование. Далее речь пойдет именно о том, как это сделать в Linux с картой памяти, впоследствии используемой Android-устройством.
Прежде чем отключить журналирование, давайте проведем сравнительный анализ Linux-ФС, которые с успехом применяются и в ОС Android:
Ext2 – вторая расширенная файловая система, пришедшая на замену оригинальной в 1993-м году. Она разработана с целью устранить имеющиеся в первой версии ограничения (максимальный размер файла увеличен до 2-х терабайт, а общий размер раздела — до 32-х терабайт) и не содержит функции журналирования.
Ext3 – третья расширенная, представленная в 2001-м году. Данная ФС оснащена 3-мя типами журналирования — journal, ordered и writeback, при этом в ней сохранены предыдущие максимальные показатели величины файла и раздела, а также присутствует возможность преобразования по схеме Ext2 -> Ext3 напрямую без резервного копирования и восстановления.
Ext4 — четвертая расширенная, появившаяся в 2008-м году. В ней «максимум для файла» увеличен до 16-ти терабайт, выделяемого пространства — до 1-го эксабайта, а папка может содержать максимум 64000 субдиректорий (в Ext3 — 32000). Кроме этого было внедрено несколько новых технологий, повышающих производительность и надежность в сравнении с предыдущей ревизией. В Ext4 появилась возможность выключить функцию ведения журнала, в чем, собственно, и суть данной статьи.
Вообще для съемных USB-дисков и других запоминающих устройств без «крутящихся механизмов», рекомендуется использовать Ext2, так как журналирование в ней отсутствует, а основных ее преимуществ (см. описание) хватит, как говорится, «с головой». Современные версии Android также имеют поддержку exFAT от Microsoft — в ней устранено ограничение в 4 гигабайта на один файл. Однако, эти файловые системы имеют определенные недостатки по сравнению с Ext4, проявляющиеся в более низкой производительности (Ext2) и меньшей совместимости (exFAT).
Поэтому лучше создать на внешнем накопителе Ext4-раздел и отключить журналирование в нем с помощью терминала Linux:
, где «/dev/sda5» — Ваша флешка или карта SD;
tune2fs -o journal_data_writeback /dev/sda5
переводим журнал в режим writeback;
tune2fs -O ^has_journal /dev/sda5
удалит соответствующую опцию;
e2fsck -f /dev/sda5
выполнит проверку диска;
dumpe2fs /dev/sda5 |more
проверит активные свойства ФС (в Filesystem features не должно быть has_journal).
Перечисленные выше команды нужно выполнять с правами администратора! На начальном этапе (создание ФС) можно применить Gparted, тогда результат будет отображаться в наглядном графическом виде. При установке раздела Ext4 на MicroSD для использования в среде Android рекомендуется оставить первым FAT32-раздел, а Ext4 определить вторым, как первичный.
Понравилась полезная статья? Подпишитесь на RSS и получайте больше нужной информации!
Отключаем журналирование EXT4
Наверняка вы знаете о том, что такое журналирование. Так вот, это в файловых системах оно нужно для того, чтобы можно было восстановить файловую систему в случае возникновения сбоя. Это особенно полезно в случаях, когда во время сбоя выполнялись операции записи данных.
Известно, что когда запись выполняется не полностью, то файловая система останется в повреждённом состоянии и её будет невозможно смонтировать. Если включить журнал, программа fsck во время загрузки системы сможет выполнить проверку и восстановить состояние из журнала. Дальше рассмотрим как отключить журналирование в Ext4.
Отключаем журнал
Как проверить включен ли для нужного раздела диска журнал? Выполните:
$ sudo dumpe2fs /dev/nvme0n1p5 | grep has_journal
Видим /dev/nvme0n1p5 — файл раздела. Может иметь и другое название. Если в строке Filesystem Features имеется has_journal, значит, журнал включён. Если он включен и все работает. Отключается журналирование файловой системы так:
$ sudo tune2fs -O ^has_journal /dev/nvme0n1p5
Если вы не желаете отключать журналирование, но при этом хотите, чтобы система была производительней, включите режим writeback. После этого в журнал данные не будут записываться, за исключением метаданных.
В первую очередь данные оказываются на диске, после чего операция записывается в журнал. В подобном режиме работы Ext4 демонстрирует наибольшую производительность.
$ sudo tune2fs -o journal_data_writeback /dev/nvme0n1p5
Как вернуть режим журналирования? Для этого можно выполнить:
$ sudo tune2fs -o journal_data_ordered /dev/nvme0n1p5
Подобно режиму writeback пользователем может быть активирована /etc/fstab. В опции монтирования раздела добавьте data=writeback:
Можно ли еще увеличить производительность? Да, добавьте опцию noatime, что отключит обновление поля последнего доступа к файлу. Это уменьшает число обращений к диску, зато продлит срок службы SSD.
Как грамотно отключить журналирование в ext4?
Для продления жизни SSD диску хочется отключить журналирование в файловой системе ext4. Но при использовании:
tune2fs -o journal_data_writeback /dev/sda1
заодно отключается и режим TRIM, несмотря на прописанную опцию discard в fstab.
Подскажите пожалуйста, возможно ли отключить журналирование без таких побочных эффектов?
- Вопрос задан более трёх лет назад
- 23878 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 4
Ответ написан более трёх лет назад
Нравится 2 5 комментариев
Zenker @Zenker Автор вопроса
Чтобы уменьшить количество обращений к диску, очевидно.
А более не очевидный ответ есть? Ведь журнал не сильно уменьшит количество обращений. Без журнала проблем больше. Ваш ССД все равно не умрет от выработки циклов чтения/записи(ну конечно если вы не гоняете каждый день по 100ГБ по винту).
Хотя если вам уж очень хочется это сделать, то
tune2fs -O ^has_journal /dev/sda1
e2fsck -f /dev/sda1
reboot
ext4 с журналированием (вся система + /home там). Без tmpfs. Единственное что было сделано это noop scheduler, sawpiness в 0, и правильная разметка разделов. Работает круглосуточно. Торренты качам/раздаем на нем же.
Model Family: SandForce Driven SSDs
Device Model: OCZ-VERTEX2
Power_On_Hours_and_Msec: 2579h+29m+52.800s
Lifetime_Writes_GiB: 896 (~8GiB/day)
Lifetime_Reads_GiB: 1152 (~10GiB/day)
SSD_Life_Left: 100
Fail Count все еще 0
Отключение журналирования ext4
На одном из серверов установлена свежая версия Ubuntu на недавно приобретенный жесткий диск, для которого в качестве базовой файловой системой была выбрана ext4. По графику процессорного времени системы мониторинга Zabbix видно, что у сервера высокий IOWait. С помощью утилит iostat и iotop были выявлены виновники столь высокой нагрузки. Ими оказались базы MySQL (активно используемые самим Zabbix‘ом) и процесс [jbd2/dm-0-8], который выполняет функцию журналирования файловой системы ext4. Причем нагрузка от второго была в разы больше, поэтому дальше будет описание процесса снижения воздействия новой файловой системы на нагрузку процессора.
Журналирование в новой файловой системе было включено не просто так, а для снижения рисков потери данных при всевозможных неожиданных сбоях в электропитании. Так как сервер, о котором идет речь в этой статье, подключен к бытовой электросети через источник бесперебойного питания, вероятность подобной проблемы крайне мала. Следовательно, можно практически безболезненно избавиться от процедуры «логирования всего и вся» в процессе работы системы.
Дисклеймер: последующие операции вы делаете на свой страх и риск, автор не несет никакой ответственности за убитые жесткие диски и потерянные важные данные.
По умолчанию в Ubuntu установлен режим journal_incompat_revoke, проверить текущее состояние можно, выполнив от учетной записи root следующую команду (указать свой раздел с ext4 вместо sdX):
dumpe2fs /dev/sdX |grep journal
Если сделать выборку по другому параметру, можно будет увидеть, ведется ли журнал:
dumpe2fs /dev/sdX |grep features
Вывод будет содержать строку с « has_journal «, если это так.
Переводим файловую систему в режим journal_data_writeback, который оставляет журналирование лишь для метаданных и тем самым заметно ускоряет производительность файловой системы:
- Загружаемся с LiveCD/LiveUSB или любым другим способом, чтобы можно было размонтировать раздел с файловой системой, требующей внесения изменений
- Выключаем журнал:
tune2fs -O ^has_journal /dev/sdX tune2fs -o journal_data_writeback /dev/sdX e2fsck -f /dev/sdX dumpe2fs /dev/sdX |grep journal dumpe2fs /dev/sdX |grep features
Ниже представлены сравнительные графики процессорного времени и дисковых операций до и после отключения журнала:
Немного теории о возможных режимах работы файловой системы, для тех кто не устал:
* writeback mode
In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode — metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance.* ordered mode
In data=ordered mode, ext4 only officially journals metadata, but it logically groups metadata information related to data changes with the data blocks into a single unit called a transaction. When it’s time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode.* journal mode
data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state. This mode is the slowest except when data
needs to be read from and written to disk at the same time where it outperforms all others modes. Curently ext4 does not have delayed allocation support if this data journalling mode is selected.
Поиск