ext4, XFS, ZFS, btrfs: как выбрать под задачу

MAATRIX

Когда разворачиваете новый сервер, установщик почти всегда предлагает файловую систему по умолчанию — и обычно на этом выбор заканчивается. Но default подходит не для всех задач: под базу данных, под хранилище на терабайты или под сервер, где важны снапшоты и защита от битых данных, разумнее выбрать осознанно. В этой статье — практическое сравнение четырёх самых распространённых файловых систем для Linux-сервера: ext4, XFS, ZFS и btrfs, без глубокого повторного разбора ZFS и btrfs (они уже разобраны отдельно) — только синтез и конкретный выбор по сценарию.

ext4: проверенный по умолчанию

ext4 — это развитие линии ext2/ext3, в проде с конца 2000-х, и именно она стоит по умолчанию в подавляющем большинстве дистрибутивов (Ubuntu, Debian, большинство сборок на базе RHEL для корневого раздела). За десятилетия эксплуатации у неё не осталось сюрпризов: поведение при сбоях, поведение fsck, поведение под нагрузкой — всё предсказуемо и задокументировано вдоль и поперёк.

Из коробки ext4 даёт:

• журналирование метаданных (по умолчанию data=ordered — данные пишутся до метаданных, что снижает риск рассинхронизации после сбоя);
• extent-based allocation (в отличие от ext3 с поблочным addressing — меньше фрагментация на больших файлах);
• поддержку файлов и разделов с большим запасом (на практике вы упрётесь в лимиты оборудования и настроек LVM раньше, чем в лимиты самой ext4).

Чего в ext4 нет — и это осознанное ограничение, а не недоработка: нет встроенных снапшотов на уровне ФС (снапшоты делаются через LVM ниже уровня файловой системы), нет сжатия, нет сквозных контрольных сумм данных (только метаданных через журнал). Именно отсутствие «продвинутых» возможностей — причина, почему ext4 остаётся разумным выбором: меньше подвижных частей — меньше того, что может сломаться неожиданным образом.

Создание раздела:

mkfs.ext4 -L data /dev/sdb1
mount -o defaults,noatime /dev/sdb1 /data

noatime в fstab стоит добавлять почти всегда на серверах — обновление времени последнего доступа на каждое чтение создаёт лишнюю запись без практической пользы для большинства сервисов.

Когда ext4 — правильный выбор: простой веб-сервер, приложение в Docker, корневой раздел системы, VPS общего назначения — везде, где не нужны снапшоты и сжатие на уровне ФС, а важна максимальная предсказуемость и совместимость с любым инструментом восстановления.

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

XFS изначально разрабатывалась в SGI для IRIX под задачи с очень большими файлами и высокой параллельной пропускной способностью, и это наследие видно в архитектуре: диск делится на allocation groups, каждая из которых может обрабатывать запросы независимо — это даёт хорошее масштабирование при параллельном I/O на многоядерных серверах. XFS — файловая система по умолчанию в RHEL/CentOS/Rocky/AlmaLinux начиная с 7-й версии, так что на серверах с этими дистрибутивами вы, скорее всего, уже её используете.

Сильные стороны:

• extent-based allocation с крупными непрерывными экстентами — меньше фрагментация на больших файлах (базы данных, образы дисков, медиатека);
• delayed logging и делегирование записи по allocation groups — хорошая производительность под параллельной нагрузкой (много потоков пишут одновременно);
• онлайн-расширение раздела «на горячую» через xfs_growfs без размонтирования.

Практическая грабля, о которой часто забывают: XFS нельзя уменьшить после создания — только увеличить. Если заложили раздел на 500 ГБ, а нужно 300 ГБ — придётся пересоздавать ФС и переносить данные, LVM здесь не спасает (в отличие от ext4, которую можно уменьшать через resize2fs). Планируйте размер заранее или используйте LVM-том с запасом для расширения в будущем.

mkfs.xfs -L data /dev/sdb1
mount -o defaults,noatime /dev/sdb1 /data
xfs_growfs /data   # расширение "на горячую" после роста LVM-тома

Как и ext4, «из коробки» XFS не даёт встроенных снапшотов и сжатия на уровне самой ФС (для этого нужен LVM или переход на ZFS/btrfs). В современных ядрах у XFS есть поддержка reflink-копий (быстрое copy-on-write клонирование файла без полного дублирования данных) — полезно для дедупликации отдельных файлов, но это не замена полноценным снапшотам тома.

Когда XFS — правильный выбор: сервер баз данных (файлы данных СУБД, не обязательно WAL-журналы), файловое хранилище с большими файлами, сервер бэкапов, где приоритет — устойчивая пропускная способность под параллельной нагрузкой, а не «продвинутые» функции ФС.

ZFS: снапшоты, сжатие, контрольные суммы — и цена за это

ZFS решает задачу иначе: это не просто файловая система, а связка «менеджер томов + ФС» с богатым набором встроенных возможностей — снапшоты и клоны на уровне датасета, прозрачное сжатие (lz4, zstd), сквозные контрольные суммы всех данных (не только метаданных — обнаруживает и, при избыточности, исправляет битые блоки), встроенный RAID-подобный функционал (RAID-Z разных уровней) без отдельного mdadm, и репликация между серверами через zfs send/zfs receive.

Мы разбирали ZFS отдельно и подробно — базовые команды pool/dataset/snapshot смотрите в статье «ZFS за 15 минут: пул, датасет, снапшот». Здесь — только вывод для сравнения: вся эта функциональность не бесплатна. ZFS ощутимо требовательнее к оперативной памяти (кэш ARC активно использует RAM, и на серверах с ZFS её закладывают с запасом), администрирование сложнее, чем «create fs and forget» у ext4/XFS, а из-за лицензии CDDL модуль ZFS исторически не входит в мейнлайн ядра Linux — на большинстве дистрибутивов его ставят отдельным пакетом (zfsutils-linux в Debian/Ubuntu, репозиторий OpenZFS для RHEL-семейства) или через DKMS, что добавляет шаг в обслуживание при обновлении ядра.

Когда ZFS — правильный выбор: файловый сервер/NAS, целевой сервер для бэкапов (снапшоты + сжатие экономят место, контрольные суммы защищают архив от тихого повреждения данных на диске), сценарии, где нужна встроенная репликация между серверами без отдельного инструмента — и где вы готовы заложить RAM с запасом и разобраться в администрировании чуть глубже, чем «одна команда mkfs».

btrfs: похожая идея, но в ядре Linux «из коробки»

btrfs решает похожий набор задач, что и ZFS — copy-on-write, снапшоты и субтомы (subvolumes), прозрачное сжатие (zstd/lzo/zlib), контрольные суммы данных и метаданных — но принципиально иначе устроена организационно: btrfs входит в мейнлайн ядра Linux, поэтому не требует отдельной установки модуля и не зависит от лицензионной коллизии, которая годами держала ZFS вне ядра. Это делает btrfs доступной «из коробки» практически на любом современном дистрибутиве без дополнительных репозиториев — она уже используется по умолчанию, например, в SUSE/openSUSE и в Fedora на десктопных установках.

Базовые операции похожи по духу на ZFS:

mkfs.btrfs -L data /dev/sdb1
mount -o compress=zstd /dev/sdb1 /data
btrfs subvolume create /data/subvol1
btrfs subvolume snapshot /data/subvol1 /data/subvol1-snap-$(date +%F)

Важная оговорка, которую стоит проговорить честно: не все возможности btrfs одинаково зрелые. Часть функциональности (в первую очередь встроенный RAID5/6 на уровне btrfs) исторически имела известные проблемы с надёжностью при сбоях (так называемый write hole) и годами не рекомендовалась для продакшена — при этом другие режимы (одиночный диск, RAID1/RAID10, снапшоты, сжатие, quota) используются в проде значительно шире и стабильнее. Отдельной статьи с детальным разбором конкретно btrfs у нас пока нет, поэтому если конкретная возможность (например, статус RAID5/6) критична для вашего сценария — проверьте актуальный статус в документации проекта и в списке известных проблем (wiki btrfs) непосредственно перед внедрением, ситуация здесь меняется от релиза к релизу.

Когда btrfs — правильный выбор: те же потребности, что и для ZFS (снапшоты, сжатие, защита от повреждения данных), но с приоритетом на встроенную поддержку в ядре без дополнительной установки модуля — и готовностью заранее проверить статус конкретно нужных вам возможностей, а не полагаться на них вслепую.

Сравнительная таблица

Как выбрать под сценарий

Если не хочется держать в голове всю таблицу — вот прямой выбор по типичной задаче:

• Простой сервер без особых требований (веб-приложение, API, корневой раздел, обычный VPS) → ext4. Максимум предсказуемости, минимум того, что может пойти не так, инструменты восстановления есть везде.
• Сервер с большими файлами или базой данных, где приоритет — производительность под параллельной нагрузкой → XFS. Учтите ограничение на уменьшение раздела — закладывайте размер тома с запасом или через LVM.
• Нужны снапшоты, сжатие и встроенная защита от повреждения данных, и вы готовы к дополнительной сложности администрирования и запасу по RAM → ZFS. Отдельно распишите бюджет памяти под ARC-кэш при планировании конфигурации сервера.
• Похожие потребности, что и для ZFS, но важна встроенная в ядро поддержка без отдельной установки модуля, и вы готовы заранее проверить статус конкретных нужных вам возможностей → btrfs. Не полагайтесь на RAID5/6 в btrfs без проверки актуального статуса — для этого сценария часто разумнее взять mdadm поверх btrfs в single/RAID1-режиме.

Если сомневаетесь между XFS и ZFS для файлового хранилища на терабайты — конфигурацию сервера под такую задачу мы разбирали в статье «Выделенный сервер для файлового хранилища на терабайты: конфигурация», а если файловая система будет работать поверх программного RAID (mdadm) — уровни RAID и их компромиссы разобраны в статье «RAID на сервере: уровни и как выбрать».

Частые вопросы