Разница между журналируемой и нежурналируемой файловой системой проявляется в момент сбоя питания. Журналируемая ФС сначала записывает в отдельный журнал намерение изменить служебные структуры и только потом применяет изменения к рабочей области. Нежурналируемая пишет метаданные сразу на место, поэтому обрыв записи оставляет дерево каталогов, карты размещения и списки свободных блоков в несогласованном состоянии.
К журналируемым относят ext4, XFS и NTFS. К нежурналируемым - FAT32, exFAT и ext2. Отдельная ветка - copy-on-write файловые системы BTRFS и ZFS: классического журнала в них нет, целостность обеспечивают атомарная замена блоков и контрольные суммы.
Практический выбор под задачу такой: серверы, NAS и базы данных - ext4, XFS, BTRFS или ZFS; флешки, SD-карты и embedded-устройства - FAT32, exFAT, ext2 либо ext4 с отключённым журналом ради ресурса носителя. Дальше разберём механику журнала транзакций, режимы журналирования ext4 и команды для проверки настроек.
Что такое журналирование файловой системы и зачем оно нужно
Журналирование - механизм, при котором файловая система ведёт журнал транзакций перед их применением к основной области. В журнал попадает описание операции над метаданными: создать файл, выделить блок, обновить индексный дескриптор. Часть ФС, например ext4 в режиме data=journal, пишет туда ещё и сами данные пользователя.
Аналогия из авиации: пилот записывает манёвр в бортжурнал до его выполнения, чтобы после сбоя восстановить последовательность действий. У ФС логика та же, только вместо пилота работает драйвер файловой системы, а вместо бортжурнала - кольцевой буфер в фиксированной области диска.
Журнал не заменяет резервное копирование. Он снижает риск повреждения метаданных при внезапном отключении питания, но не спасает от физического отказа диска, ошибки RAID-контроллера, сбоя прошивки SSD или логической ошибки приложения, которое записало мусор поверх нужных данных.
У нежурналируемых ФС после сбоя остаётся один инструмент - fsck. Утилита сканирует индексные дескрипторы, битовые карты, каталоги и сверяет их между собой. На томах в несколько терабайт такая проверка идёт десятки минут, а иногда и часы.
Как журнал транзакций защищает метаданные при сбоях питания
Порядок операций у журналируемой ФС:
- Драйвер получает запрос на изменение метаданных, например на создание нового файла.
- Запись о намерении уходит в журнал. Транзакция считается зафиксированной только после сброса журнала на носитель.
- После фиксации изменения применяются к основной области: обновляются индексные дескрипторы, карты блоков, каталоги.
- Транзакция помечается как завершённая и освобождает место в журнале.
Если питание пропало между шагами 2 и 3, при следующей загрузке ФС читает журнал и либо дописывает незавершённую транзакцию, либо откатывает её. Восстановление ext4 по журналу обычно укладывается в секунды, потому что проверяется только область журнала, а не весь том. Полная проверка ext2 на диске 4 ТБ может идти десятки минут: утилита обязана обойти всю структуру, потому что достоверного списка незавершённых операций у неё нет.
Время fsck и накладные расходы журналирования зависят от модели носителя, размера тома, версии ядра и утилит. Приведённые в статье значения стоит воспринимать как типичные ориентиры, а не как норматив: цифры для своей конфигурации подтверждайте на тестовом стенде.
Ключевые различия между журналируемыми и нежурналируемыми файловыми системами
Сравнивать категории удобно по трём осям: архитектура, поведение при сбое, стоимость записи.
| Критерий | Журналируемая ФС | Нежурналируемая ФС |
|---|---|---|
| Запись метаданных | Сначала в журнал, затем в рабочую область | Сразу в рабочую область |
| Сбой питания | Replay журнала за секунды | Полная проверка fsck |
| Накладные расходы | Двойная запись метаданных, обычно единицы процентов | Минимальные |
| Целостность метаданных | Гарантирована на уровне транзакции | Не гарантирована |
| Типичные примеры | ext4, XFS, NTFS, ReFS | FAT32, exFAT, ext2 |
Copy-on-write ФС стоят особняком. BTRFS и ZFS не перезаписывают блоки на месте: новые данные и метаданные ложатся в свободные блоки, а указатель в дереве переключается одной атомарной операцией. Журнал им не нужен, потому что предыдущее состояние остаётся целым до момента переключения.
Журналируемые файловые системы: ext4, XFS, NTFS
ext4 - стандарт по умолчанию в большинстве дистрибутивов Linux. Журналирует метаданные, поддерживает экстенты, отложенное выделение блоков, максимальный размер файла 16 ТБ и тома до 1 ЭБ. Полное сравнение ограничений, прав доступа и совместимости с разными ОС собрано в материале NTFS, exFAT, FAT32, ext4 и другие файловые системы: что выбрать в 2026 году.
XFS создавали для больших файлов и параллельного ввода-вывода. Несколько потоков пишут одновременно, а ФС делит пространство на allocation groups и снижает конкуренцию за блокировки. Журнал ведётся только для метаданных, есть отложенное логирование (delayed logging). Типичный выбор для файловых серверов, медиахранилищ и лог-серверов.
NTFS держит журнал $LogFile для метаданных и восстанавливается после сбоя без полной проверки тома на Windows-системах. Дополнительно она даёт права ACL, теневые копии, квоты и шифрование EFS.
Нежурналируемые файловые системы: FAT32, exFAT, ext2
FAT32 остаётся на устройствах, где важна максимальная совместимость: фотоаппараты, старые прошивки, загрузочные разделы UEFI. Ограничения жёсткие: файл не больше 4 ГБ, том обычно до 2 ТБ при секторах 512 байт. Журнала нет, поэтому извлечение носителя без размонтирования грозит потерей данных.
exFAT пришла на смену FAT32 для флешек и внешних SSD: снимает лимит 4 ГБ на файл, работает с томами в сотни терабайт, поддерживается Windows, Linux, macOS и Android. Журналирования в ней тоже нет.
ext2 сохранилась в embedded-мире: минимальный код, предсказуемое потребление памяти, никаких накладных расходов журнала. На роутерах, промышленных контроллерах и одноплатных компьютерах она встречается до сих пор, часто вместе с корнем, смонтированным только для чтения.
Для нежурналируемых ФС критично корректное размонтирование: umount перед извлечением носителя. У смонтированного тома часть изменений ещё лежит в кэше страниц и до диска не дошла.
Компромисс между производительностью записи и целостностью данных
Журналирование стоит денег: одну и ту же запись метаданных ФС делает дважды, сначала в журнал, потом в целевой блок. На типичных серверных нагрузках накладные расходы оценивают в 5-15% по пропускной способности, а на тестах с массовым созданием мелких файлов разрыв заметнее. Как измерить разницу на своём железе, показано в статье производительность файловой системы: как измерить и на что влияет.
На SSD добавляется второй фактор - износ ячеек. Каждая транзакция расходует ресурс перезаписи, но у серверных накопителей запас измеряется в DWPD (полных перезаписей в день) и обычно составляет не меньше 1, а выравнивание износа и TRIM распределяют запись по свободным блокам. Итоговый вклад журнала в общий объём записи остаётся небольшим.
Режимы журналирования ext4: ordered, writeback, journal
- data=ordered (по умолчанию): журнал хранит метаданные, данные попадают на диск до фиксации метаданных. После сбоя не появится файл с мусорным содержимым. Подходит большинству серверов.
- data=writeback: журналируются только метаданные, порядок записи данных не контролируется. Скорость выше, но после сбоя возможен файл со старым или нулевым содержимым при формально корректных метаданных. Оправдан для кэшей, временных разделов, файловых архивов.
- data=journal: в журнал пишутся и метаданные, и данные. Максимум гарантий и заметное падение пропускной способности записи, поэтому режим берут для критичных данных небольшого объёма.
NTFS и XFS такой гибкости не дают: первый пишет в $LogFile только метаданные, второй журналирует исключительно метаданные и полагается на delayed logging для группировки транзакций.
Когда журналирование избыточно: флешки и embedded-устройства
На microSD и USB-флешках журнал часто отключают: у дешёвых карт ресурс перезаписи низкий, а каждая транзакция добавляет цикл записи. Raspberry Pi с корнем на microSD - типовой пример: постоянная запись логов и метаданных быстро добивает карту.
Embedded-устройства идут дальше и монтируют корень в read-only. Изменяемые каталоги вроде /var, /tmp и /etc выносят в tmpfs или на отдельный носитель, а перезагрузка возвращает исходное состояние. Журналирование в такой схеме не нужно: записи в корень просто нет.
Риск у нежурналируемых носителей один и предсказуемый: внезапное отключение питания или извлечение флешки посреди записи. Закрывается он ИБП для стационарных устройств, корректным выключением и регулярными резервными копиями.
Особенности работы с microSD и USB-флешками
Рабочие настройки для сменных носителей:
- Монтирование ext4 с опцией noatime, чтобы метка доступа не обновлялась при каждом чтении: mount -o noatime,data=writeback /dev/sdb1 /mnt.
- Строка в /etc/fstab для постоянного режима: /dev/sdb1 /mnt ext4 defaults,noatime,data=writeback 0 2.
- Создание раздела с журналом: mkfs.ext4 /dev/sdb1. Создание без журнала: mkfs.ext4 -O ^has_journal /dev/sdb1.
- Отключение журнала на уже существующем ext4-разделе: tune2fs -O ^has_journal /dev/sdb1. Перед командой сделайте копию данных, а обратное включение журнала потребует проверки тома.
- На картах от 128 ГБ журнал можно оставить: объём служебной записи для такого носителя не критичен.
Если нужна совместимость с Windows и macOS, берите exFAT: она тоже нежурналируемая, но лишена лимита FAT32 в 4 ГБ на файл.
Режимы монтирования удобно отрабатывать на отдельной виртуалке, а не на рабочей системе: Timeweb Cloud предоставляет VDS и хранилище, где можно поднять тестовый стенд с ext4, смоделировать отключение питания и посмотреть, как ФС восстанавливается.
Когда журналирование критично: серверные диски и NAS
Серверный диск работает круглосуточно и принимает записи от десятков процессов. Отказ блока питания, перезагрузка по watchdog, аварийное выключение стойки происходят на фоне незавершённых транзакций. База данных MySQL или PostgreSQL на ext4 с data=ordered поднимается после такого сбоя без ручного запуска fsck: журнал откатывает незакрытые изменения метаданных.
Для систем с высокой нагрузкой на запись (лог-серверы, брокеры сообщений, сбор метрик) подходит XFS с журналированием метаданных: она держит параллельную запись и не перестраивает карты блоков целиком. Файловые серверы с крупными файлами тоже часто живут на XFS.
Современные ФС: BTRFS и ZFS вместо классического журнала
BTRFS и ZFS решают задачу целостности другим способом. Каждый блок данных и метаданных получает контрольную сумму, а переключение дерева выполняется атомарно. Если блок не сошёлся по чек-сумме, ФС читает копию при её наличии и сообщает о повреждении вместо тихой выдачи мусора. Журнала в классическом понимании здесь нет, но гарантии после сбоя питания сопоставимы.
Пример современного NAS: TerraMaster F4-212 поддерживает BTRFS, снапшоты и инструмент аварийного восстановления TFSS, а работает под управлением TOS 5, где заявлено более 50 новых функций и 600 улучшений к прошлому поколению (TerraMaster F4-212). Массивами управляет TRAID, технология с автоматическим объединением дискового пространства, защитой от отказа диска и расширением ёмкости (там же).
ZFS просит больше ресурсов: на каждый терабайт хранилища планируют около 1 ГБ оперативной памяти плюс кэш ARC, зато получают сжатие, дедупликацию и снапшоты на уровне пула. Подробное сравнение CoW-систем и классических ФС для массивов разобрано в статье ZFS, XFS и Btrfs для СХД: что выбрать в 2026.
Как выбрать режим журналирования под разные нагрузки: практические рекомендации
Сводка по типовым задачам:
| Сценарий | ФС и режим | Почему так |
|---|---|---|
| Домашний NAS | BTRFS со снапшотами | Целостность на уровне чек-сумм и откат версий файлов |
| Сервер баз данных | ext4 с data=ordered или XFS | Метаданные защищены, падение скорости минимально |
| Лог-сервер, брокер сообщений | XFS | Параллельная запись без общей блокировки |
| Файловый сервер, медиатека | XFS или ext4 | Крупные файлы и высокая пропускная способность |
| Флешки и SD-карты | exFAT или ext4 с data=writeback | Экономия ресурса перезаписи |
| Embedded-устройства | ext2 или ext4 в read-only | Записи в корень нет, журнал не нужен |
| Критичные данные малого объёма | ext4 с data=journal | Максимум гарантий по данным и метаданным |
Проверка и изменение режима журналирования: команды
- Посмотреть текущий режим и параметры раздела: tune2fs -l /dev/sda1 | grep 'Default mount options'.
- Задать режим по умолчанию для раздела: tune2fs -o journal_data_writeback /dev/sda1. Обратная операция: tune2fs -o journal_data_ordered /dev/sda1.
- Смонтировать том с нужным режимом: mount -o data=writeback /dev/sda1 /mnt.
- Переключить режим на работающей системе: mount -o remount,data=writeback /, права root обязательны.
- Закрепить настройку в /etc/fstab: /dev/sda1 /mnt ext4 defaults,data=ordered 0 2.
Меняйте режим сначала на тестовом стенде: часть ошибок проявляется только при следующем сбое питания, когда откатывать изменения уже поздно.
Итог: что выбрать в 2026 году
Для серверов и NAS берите ФС с гарантией целостности: ext4 с data=ordered, XFS либо copy-on-write BTRFS и ZFS. Для флешек, SD-карт и embedded-устройств нежурналируемые варианты или отключённый журнал оправданы: вы экономите ресурс носителя там, где запись либо минимальна, либо отсутствует вовсе.
Классическое журналирование остаётся рабочим инструментом в ext4 и XFS, а BTRFS и ZFS предлагают другой путь: контрольные суммы и атомарная замена блоков. Пример такого подхода - TerraMaster F4-212 с BTRFS, TRAID и снапшотами, где целостность данных обеспечивается без традиционного журнала.
Любую смену режима монтирования проверяйте на стенде и держите актуальные резервные копии: журнал защищает метаданные, но не заменяет бэкап. Как выстроить копирование и снапшоты, разобрано в материале резервное копирование и снапшоты в системе качества хранения данных.