Файловые системы Linux в 2026: сравнение ext4, XFS и Btrfs и выбор под задачу

Какую файловую систему Linux выбрать в 2026 году: краткий ответ

Для серверных сценариев в 2026 году выбор сводится к трём нативным файловым системам Linux: ext4, XFS и Btrfs. ext4 остаётся универсальным вариантом по умолчанию: корневой раздел, веб-сервер, небольшая база данных, файловый сервер общего назначения. XFS берут там, где преобладают крупные файлы, длинные последовательные записи и параллельный доступ: медиахранилища, потоки резервного копирования, каталоги с сотнями тысяч записей. Btrfs выбирают ради снапшотов, сжатия на лету и откатов состояния системы.

Задача уточняет ответ быстрее любой таблицы. Для PostgreSQL и MySQL при объёмах в сотни гигабайт и смешанной нагрузке подходит ext4; при терабайтах данных и одновременной записи нескольких процессов аргументы в пользу XFS усиливаются. Веб-хостинг с миллионами мелких файлов чувствителен к запасу inode и к скорости обхода каталогов. Файловое хранилище крупных объектов выигрывает от последовательной записи XFS, а там, где нужны снапшоты и сжатие, удобнее Btrfs.

Одно ограничение стоит учитывать до форматирования: место под данные и пул inode это два независимых ресурса файловой системы. Байты содержимого и число объектов считаются раздельно, поэтому свободные гигабайты не гарантируют, что очередной файл удастся создать. Разбор этой ситуации с примерами счётчиков приведён в материале про место и inode как независимые ограничения файловой системы.

Почему ext4 остаётся стандартом де-факто в 2026 году

Линия ext4 начинается с ext3: она вышла в сентябре 1999 года, её написал Stephen Tweedie для ветки ядра 2.2, а на ветку 2.4 портировали Peter Braam, Andreas Dilger, Andrew Morton, Alexander Viro, Ted Ts'o и Stephen Tweedie. ext3 это ext2, дополненная журналированием, и одновременно подмножество ext4, поэтому доступ к томам ext3 обеспечивает драйвер ext4 (см. документацию ядра Linux по ext3). Такая преемственность даёт главное эксплуатационное свойство: поведение ФС предсказуемо, а инструменты есть в базовой поставке любого дистрибутива.

Онлайн-расширение, проверка утилитой e2fsck и настройка через tune2fs выполняются без пересоздания тома. Загрузчики, системы резервного копирования, снапшоты LVM и квоты работают с ext4 без дополнительных драйверов. Резерв 5% блоков для root оставляет запас привилегированным процессам, когда диск заполнен обычными пользователями, а изменить или снять его позволяет команда tune2fs -m 1 /dev/sdX1.

Команды создания и монтирования ext4

Создание тома: mkfs.ext4 /dev/sdX1, метка задаётся ключом -L, например mkfs.ext4 -L data /dev/sdX1. Монтирование вручную: mount /dev/sdX1 /mnt/data. Постоянное подключение описывают в /etc/fstab по UUID, который показывает blkid:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/data ext4 defaults,noatime 0 2

После правки файла выполняют mount -a и проверяют результат тремя командами: df -h /mnt/data показывает занятое место, df -i /mnt/data показывает расход inode, tune2fs -l /dev/sdX1 выводит параметры ФС, включая размер блока и общее число inode. Опция noatime убирает обновление времени доступа при чтении и снижает лишние записи, а discard передаёт команды TRIM на SSD, хотя на большинстве дистрибутивов TRIM уже выполняется по таймеру systemd.

Особенности журналирования ext4

Журнал хранит намерения изменить метаданные, поэтому после сбоя том возвращается в согласованное состояние за секунды, без полной проверки всех блоков. Режим задают опцией монтирования. journal пишет в журнал и данные, и метаданные; ordered, режим по умолчанию, гарантирует запись данных раньше метаданных; writeback журналирует только метаданные и даёт наибольшую скорость при самом слабом уровне целостности. Текущий режим видно в /proc/mounts или в выводе команды mount.

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

XFS: файловая система для больших файлов и высоких нагрузок

XFS делит том на группы размещения (allocation groups), каждая со своим набором свободных блоков и собственной частью журнала. Несколько потоков записи работают параллельно и не выстраиваются в очередь к одному журналу. На крупных файлах, длинных последовательных записях и каталогах с сотнями тысяч записей такое устройство даёт заметный выигрыш. Типичные места XFS: медиасерверы, приёмники резервных копий, хранилища образов виртуальных машин, базы данных объёмом в терабайты.

Команды создания и монтирования XFS

Создание: mkfs.xfs /dev/sdX1. Если на устройстве остались подписи прежних ФС, добавляют ключ -f: mkfs.xfs -f /dev/sdX1. Монтирование: mount /dev/sdX1 /mnt/data, постоянная запись в /etc/fstab по UUID, как и для ext4. Проверка параметров выполняется командой xfs_info /mnt/data: она показывает размер блока, число групп размещения, размеры журнала и версию формата. Для расширения после роста раздела или LUN применяют xfs_growfs /mnt/data. Занятое место и расход inode смотрят через df -h и df -i.

Ограничения XFS, о которых нужно знать

Уменьшать XFS нельзя: поддерживается только рост. Раздел планируют с запасом, а данные перед любыми операциями с томом копируют на другой носитель. Проверка целостности xfs_repair требует размонтированного тома, поэтому окно обслуживания продумывают заранее. Inode выделяются динамически, и упереться в их лимит сложнее, чем на ФС с фиксированным пулом: доля пространства, доступная под inode, ограничена параметром imaxpct. По данным man-страницы mkfs.xfs, значение по умолчанию составляет 25% для ФС менее 1 ТБ, 5% для ФС менее 50 ТБ и 1% для ФС более 50 ТБ, то есть на крупных томах это небольшая часть объёма. При заполнении тома запись останавливается с ошибкой ENOSPC, часть места зарезервирована под служебные нужды, поэтому рабочий порог заполнения держат ниже 100%.

Btrfs: снапшоты, сжатие и современные возможности

Btrfs построена на copy-on-write: новый блок записывается в свободное место, а корень дерева переключается на обновлённую версию. Отсюда её преимущества. Снапшот это новая ссылка на существующее дерево, поэтому он создаётся за секунды и не останавливает сервис. Сжатие zstd или lzo уменьшает объём текстовых данных, логов и слоёв контейнеров. Профили RAID 0, 1 и 10 собираются средствами самой ФС, без mdadm. Обратная сторона той же механики: при обновлении блока данные пишутся в новое место, и файлы со случайным доступом со временем фрагментируются. Как это устроено на уровне блоков, разобрано в статье про Copy-on-Write в ZFS и Btrfs против ext4 и XFS.

Команды создания и монтирования Btrfs

Создание: mkfs.btrfs /dev/sdX1, для массива из двух дисков с зеркалированием данных и метаданных: mkfs.btrfs -d raid1 -m raid1 /dev/sdX1 /dev/sdY1. Монтирование: mount /dev/sdX1 /mnt/data. Разделение на сабволюмы: btrfs subvolume create /mnt/data/@data. Снапшот сабволюма: btrfs subvolume snapshot /mnt/data/@data /mnt/data/@data-snap. Просмотр структуры и расхода: btrfs subvolume list /mnt/data и btrfs filesystem usage /mnt/data, вторая команда отдельно показывает занятое место под данные, метаданные и системные блоки. В /etc/fstab для сжатия указывают опции compress=zstd:3,noatime.

Btrfs в NixOS и сценарии с Impermanence

Garuda Nix, самостоятельный проект на базе NixOS, применяет Btrfs в иммутабельных сценариях. Функция Impermanence автоматически удаляет выбранные системные данные после перезагрузки, при этом настроенные файлы и каталоги остаются в системе. В Garuda Nix она работает двумя путями: через откаты Btrfs на системах с Btrfs или через размещение корневой ФС в tmpfs при ext4. Установку выполняют графическим установщиком Calamares или из командной строки, а Chaotic Nyx, аналог репозитория Chaotic-AUR от Garuda, добавляет готовые пакеты в экосистему Nix (см. описание проекта Garuda Nix). NixOS описывает состояние системы декларативно, и это хорошо сочетается со снапшотами: перед обновлением делают снимок корневого сабволюма и возвращаются к нему, если изменение сломало загрузку.

Сравнение ext4, XFS и Btrfs: таблица отличий

Числа о размерах это теоретические пределы формата по документации; практический максимум задают размер блока, версия ядра и особенности нижележащего хранилища. Для ext4 документация называет том до 64 ЗиБ и файл до 16 ТиБ при стандартном блоке 4 КиБ. Для XFS подтверждён теоретический максимум размера файла 8 ЭиБ минус 1 байт, а также максимальное смещение разреженных файлов 8 ЭиБ; максимальный размер самой ФС в доступных источниках прямо не указан. Для Btrfs собственный предел длины файла составляет 16 ЭиБ, но практический предел Linux VFS ниже — 8 ЭиБ; максимальный размер ФС Btrfs в источниках прямо не подтверждён. Разница между ФС на одних и тех же дисках проявляется прежде всего на случайных операциях и на смешанной нагрузке, а не на чтении одного крупного файла. Методику замеров с fio и iostat вместе с настройками под базы данных и файловый сервер описывает отдельная статья про производительность файловой системы.

Три ФС расходятся по характеру, а не по возрасту. ext4 это универсал с предсказуемым поведением, XFS оптимизирована под масштаб и параллелизм, Btrfs даёт гибкость управления данными ценой более сложной эксплуатации. ZFS остаётся отдельным вариантом с собственным набором компромиссов, и её разбор выходит за рамки материала про нативные ФС ядра.

Выбор файловой системы под задачу: база данных, веб-хостинг, хранилище

Ниже три сценария, которые чаще всего всплывают при разметке сервера.

Файловая система для PostgreSQL на Linux

Для PostgreSQL и MySQL рабочая связка в 2026 году это ext4 или XFS. На томах до нескольких сотен гигабайт со смешанной нагрузкой ext4 показывает стабильный результат и упрощает обслуживание. При терабайтах данных, большом числе одновременных сессий и тяжёлой записи WAL преимущество получает XFS за счёт групп размещения. Практическая настройка: отдельный том под данные, mkfs.xfs /dev/sdX1 или mkfs.ext4 /dev/sdX1, монтирование с опцией noatime, размер блока по умолчанию 4 КБ подходит большинству инсталляций.

Btrfs под каталог данных требует отключения CoW: без этого обновление страниц ведёт к постоянной записи новых блоков и росту фрагментации. Атрибут снимают до заполнения каталога командой chattr +C /var/lib/postgresql, а существующие данные переносят в каталог, созданный с этим атрибутом. Сжатие на данных СУБД обычно не включают: содержимое страниц сжимается плохо, а процессорное время расходуется. Журнал WAL и табличные пространства разносят по разным томам, чтобы потоки записи не конкурировали за одни группы размещения.

Файловая система для веб-хостинга

Хостинг с миллионами мелких файлов упирается в две величины: скорость обхода каталогов и запас inode. ext4 создаёт фиксированный пул inode при форматировании; по умолчанию количество байт на inode обычно составляет 16384, это значение inode_ratio в /etc/mke2fs.conf, которое считывается перед созданием файловой системы. XFS выделяет inode динамически, и на проектах с огромным числом мелких объектов это снижает риск отказа записи, а крупные каталоги она обходит эффективнее. Практические шаги: mkfs.ext4 -i 8192 /dev/sdX1 для плотной укладки мелких файлов, монтирование с noatime, вынос кэша и сессий на отдельный носитель, контроль расхода через df -i.

Файловая система для файлового хранилища

Хранилище крупных объектов выигрывает от XFS: последовательная запись и чтение больших файлов, параллельный доступ, отсутствие проблем с гигантскими каталогами. Если нужны снапшоты, сжатие и контрольные суммы блоков, берут Btrfs, но планируют дефрагментацию и закладывают запас по ресурсам. Для NAS на несколько дисков сравнение выходит за рамки нативной тройки, и профили смотрите в статье про файловые системы для СХД: ZFS, XFS и Btrfs.

Перед разметкой стоит определить, какой тип хранилища нужен сервису: блочный том, файловый доступ или объектное хранилище. От этого зависит не только ФС, но и протокол, и способ масштабирования; критерии выбора разобраны в материале про объектное, блочное и файловое хранилище. Резервное копирование настраивают до первой записи данных: снапшот Btrfs защищает от ошибки оператора, но не от отказа диска, если сабволюм лежит на том же устройстве.

Подводные камни при работе с файловыми системами Linux

Исчерпание inode: почему свободное место не помогает

Байты содержимого и число объектов файловая система считает раздельно. На ФС с ограниченным пулом inode множество маленьких файлов исчерпывает ресурс создания объектов раньше, чем заканчивается место под данные. Свободные гигабайты не гарантируют возможность создать ещё один файл: новый файл требует inode, и при исчерпанном пуле запись не проходит. Сценарии, которые встречаются в диагностике: свободно 0 МиБ и 80 000 inode; свободно 6 000 МиБ и 0 inode; свободно 6 000 МиБ и 80 000 inode, когда очевидного исчерпания обоих ресурсов нет и причину ищут в коде ошибки, режиме монтирования и квотах (см. разбор места и inode).

Удаление множества пустых файлов помогает слабо, если основной объём занят крупным объектом: освобождаются inode, а не гигабайты. Возможен и обратный случай, когда гигабайты освободили, а лимит объектов остался прежним, потому что пул inode у ext4 фиксируется при создании тома.

Как правильно диагностировать проблемы с местом

Диагностику начинают с той файловой системы, куда идёт запись. Показания соседнего раздела не объясняют отказ, даже если он расположен рядом в дереве каталогов: путь назначения может оказаться отдельной точкой монтирования. Проверить это позволяют df -h /путь, findmnt /путь и stat -f /путь. Дальше сравнивают df -h и df -i для найденного тома.

Простая модель из двух счётчиков не учитывает квоты, резерв для привилегированных записей, служебные метаданные, thin pool и динамическое выделение inode. Если место и inode в норме, а запись не идёт, проверяют квоты через repquota или xfs_quota, смотрят вывод dmesg на ошибки ввода-вывода и убеждаются, что том не переведён в режим только для чтения после сбоя. Порядок действий такой: определить точку монтирования, сверить место и inode именно этого тома, исключить квоты и ошибки устройств, и только затем менять параметры ФС.

Практические рекомендации и итоги

Чек-лист перед разметкой сервера:

• Определите профиль нагрузки: крупные последовательные потоки, множество мелких файлов или смешанная работа с частыми обновлениями.
• Проверьте, что выбранная ФС собрана в вашем ядре: modinfo ext4, modinfo xfs, modinfo btrfs или наличие записи в /proc/filesystems.
• Оцените запас inode заранее: на ext4 пул фиксируется при создании тома, на XFS и Btrfs он растёт динамически.
• Уточните, нужны ли снапшоты, сжатие и откаты: без них Btrfs добавляет сложность без выигрыша.
• Оставьте запас под служебные нужды и квоты, не планируйте заполнение тома до 100%.
• Прогоните нагрузочный тест на стенде с реальным профилем ввода-вывода, прежде чем переносить боевые данные.
• Настройте резервное копирование до первой записи и хотя бы раз проверьте восстановление.

Выбор в 2026 году выглядит так: ext4 ставят по умолчанию, когда нет причин для другого; XFS берут под большие файлы, параллельную запись и крупные каталоги; Btrfs выбирают там, где нужны снапшоты, сжатие и откаты. Все три ФС входят в основное ядро Linux и поддерживаются сообществом, поэтому решение можно поменять на этапе разметки без смены платформы. Начните с команды df -i на действующем сервере: она сразу покажет, есть ли у текущей ФС запас по числу объектов и не придётся ли менять её раньше, чем закончится место под данные.