ext4 vs xfs vs btrfs vs zfs — когда какую

«Какую файловую систему выбрать?» — вопрос, который встаёт перед каждым, кто настраивает новый сервер, создаёт хранилище под Docker, поднимает базу данных, или просто меняет диск. В Linux есть как минимум четыре серьёзных кандидата: ext4 (дефолт большинства дистрибуций), xfs (стандарт RHEL/CentOS), btrfs (modern features, нестабильность некоторых), zfs (enterprise-grade, но не в mainline kernel). Каждая решает разные задачи, и выбор не очевидный.

В этом уроке: сравнительная характеристика по ключевым параметрам — надёжность, производительность, snapshots, размер, deduplication, compression, дозревание. Когда какая правильна, и когда не стоит выбирать «модную» в ущерб надёжной.

Сравнительная таблица: одним взглядом

ext4 — золотой стандарт

ext4 — самая распространённая Linux FS. Эволюция: ext (1992) -> ext2 (1993) -> ext3 (2001, добавлено журналирование) -> ext4 (2008, extents, большие файлы).

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

• Зрелость. 15+ лет в production. Все edge cases выявлены, все баги поправлены.
• fsck. Хорошо работает с recovery. Понятные ошибки.
• Поддержка везде. Любая дистрибуция, любой kernel, любая cloud platform.
• Performance для типичных workloads — хорошая, иногда лучше xfs на metadata-heavy.

Слабости:

• Нет snapshots. Если нужно — через LVM (LVM snapshots на уровне block).
• Нет CoW. Каждая запись изменяет старые блоки — нет cheap snapshots.
• Нет встроенной compression. Только sparse files.
• Лимиты: file 16 ТБ (с extents), FS до 1 ЭБ — более чем достаточно для современных задач.
• Inode-количество фиксировано при mkfs. Может закончиться.

# Создать ext4 FS:
sudo mkfs.ext4 /dev/sdb1

# С опциями для optimization:
sudo mkfs.ext4 -L mydata -m 1 -O ^huge_file /dev/sdb1
#               ^^^^^^^^^^ ^^^^^ ^^^^^^^^^^^^^^^
#               label     reserved 1% (вместо 5%)   опция features

# Tune later:
sudo tune2fs -l /dev/sdb1     # показать parameters
sudo tune2fs -m 1 /dev/sdb1   # изменить reserved % без размонтирования
sudo tune2fs -L newlabel /dev/sdb1

Используйте ext4, когда нет специфических требований к snapshots/CoW. 90% серверов, 99% рабочих машин. Дефолт от Canonical, Debian, основа Ubuntu cloud images.

xfs — параллельность и большие данные

xfs создавался Silicon Graphics в 90-е для high-end Unix workstations (IRIX) — нужны были большие файлы, большая параллельность. Открыт под GPL, портирован в Linux в начале 2000-х.

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

• Allocation groups. FS разделена на independent groups, каждая может работать параллельно. Идеально для multi-CPU NUMA серверов.
• 64-bit на всё. Большие файлы (16 EB), много файлов в директории, большие FS.
• Dynamic inodes. Нет фиксированного количества — inodes выделяются по мере необходимости. Никогда не упрётесь в IUsed 100%.
• High metadata performance. Журналирование metadata быстрое.
• Default в RHEL/CentOS 7+.

Слабости:

• Нельзя shrink. Только grow. Если переоценили размер — бэкап + reformat.
• Нет CoW, snapshots. Как ext4 — нужен LVM.
• fsck реже нужен и тяжелее. Журналирование быстро восстанавливает после crash.

# Создать xfs:
sudo mkfs.xfs /dev/sdb1

# С опциями:
sudo mkfs.xfs -L data -b size=4096 -d agcount=16 /dev/sdb1
#              ^^^^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
#              label   4 КБ блоки    16 allocation groups (под кол-во CPU)

# Расширить:
sudo xfs_growfs /mountpoint
# Online, без размонтирования

xfs побеждает ext4 на high-concurrency workloads и больших файлах. Базы данных (PostgreSQL, MySQL), видеостудии, аналитика. Default в RHEL family.

btrfs — modern features в mainline

btrfs (B-tree File System) — ответ Linux-сообщества на ZFS. Появился в 2007, mainline с 2.6.29 (2009). Цель — те же features (CoW, snapshots, RAID), но в kernel-tree.

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

• Copy-on-Write. Каждое изменение — новый блок, старый не трогается. Снапшоты дёшевы (просто захват CoW-моментa).
• Snapshots and subvolumes. Snapshot за миллисекунды, не зависит от размера данных.
• Built-in compression. zlib, lzo, zstd на уровне ФС. Заметная экономия места для логов, текстов.
• Integrated RAID. RAID0, 1, 10 production-ready. RAID5/6 — experimental (write hole problem).
• Checksumming. Каждый блок имеет CRC32C — silent corruption детектируется.
• Online operations. Grow, shrink, balance, scrub без unmount.
• Send/receive. Эффективная инкрементальная репликация снапшотов.

Слабости:

• RAID5/6 не production-ready. До сих пор known data loss scenarios.
• Performance менее предсказуем. Особенно с CoW и snapshots — write amplification.
• Меньшая зрелость по сравнению с ext4/xfs. Хотя в 2025 многое решено.
• fsck сложнее. btrfs-check не такой intuitive.

# Создать btrfs:
sudo mkfs.btrfs /dev/sdb1
# или несколько устройств сразу (RAID):
sudo mkfs.btrfs -m raid1 -d raid1 /dev/sdb1 /dev/sdc1

# Subvolumes:
sudo btrfs subvolume create /mnt/btrfs/data
sudo btrfs subvolume create /mnt/btrfs/snap_2026_05_18

# Снапшот:
sudo btrfs subvolume snapshot /mnt/btrfs/data /mnt/btrfs/data_snap

# Список снапшотов:
sudo btrfs subvolume list /mnt/btrfs

# Включить compression:
sudo mount -o compress=zstd /dev/sdb1 /mnt/btrfs

btrfs хорош, когда нужны snapshots и/или compression без VM/LVM. SUSE официально использует btrfs root для snapper rollback. Fedora Server переключилась на btrfs default. NAS типа Synology используют btrfs.

zfs — enterprise-grade

zfs создан Sun Microsystems для Solaris в 2005. После приобретения Oracle переведён на CDDL, что несовместимо с GPL Linux kernel. Поэтому zfs не в mainline — но есть OpenZFS (zfs on Linux), который ставится как DKMS module или через packaged kernel modules.

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

• Pool-based storage. Не разделы, а pools (vdevs), которые можно расширять, добавлять зеркала.
• Snapshots and clones. Бесплатные снапшоты, дёшевые клоны (writable snapshot).
• Send/receive. Replication между серверами на блоковом уровне.
• Compression. lz4 default, zstd, gzip.
• Deduplication. Block-level dedup (cost: memory).
• ARC cache. Aggressive RAM-based caching, очень эффективен.
• Encryption. Per-dataset native encryption (с 0.8).
• Self-healing. На RAID-Z массивах автоматически чинит bit-rot из mirror.
• Checksumming. SHA256/Fletcher4 per block.

Слабости:

• NOT in Linux mainline. Установка через DKMS или packaged module. Может сломаться при обновлении kernel.
• License (CDDL vs GPL). Не distributed Canonically Ubuntu (хотя они shipping zfs-utils).
• Memory hungry. ARC любит RAM, dedup требует много RAM. Рекомендуют 1 ГБ RAM на 1 ТБ data с dedup.
• Сложность. Многие knobs, легко настроить плохо для своего workload.

# Установка на Ubuntu:
sudo apt install zfsutils-linux

# Создать pool:
sudo zpool create mypool /dev/sdb /dev/sdc
sudo zpool status

# Mirror (RAID1):
sudo zpool create mymirror mirror /dev/sdb /dev/sdc

# RAID-Z (как RAID5, но без write hole):
sudo zpool create mypool raidz /dev/sdb /dev/sdc /dev/sdd /dev/sde

# Создать dataset (~подмножество):
sudo zfs create mypool/data

# Snapshot:
sudo zfs snapshot mypool/data@2026-05-18
sudo zfs list -t snapshot

# Send/receive (replication):
sudo zfs send mypool/data@snap1 | ssh backup-host zfs receive backup/data

# Compression на уровне dataset:
sudo zfs set compression=zstd mypool/data

zfs — стандарт для serious storage: NAS, backup-серверы, ZFS storage appliances (TrueNAS, FreeNAS). На FreeBSD это default.

Реальные сценарии выбора

Несколько конкретных кейсов:

Сервер с PostgreSQL/MySQL:

• ext4 или xfs. xfs выигрывает на больших БД (>1 ТБ) и многоядерных серверах. ext4 — безопасный default.
• Не btrfs CoW — write amplification может убить DB performance.
• Не zfs root, но zfs для отдельного data volume — OK (нативный snapshot + send/receive для бэкапов).

Docker host:

• ext4 или xfs для root. Не btrfs root (некоторые docker storage драйверы конфликтуют).
• Docker может использовать overlay2 поверх любой ФС — работает на ext4.
• btrfs storage driver для Docker — работает, но менее распространён.

Backup server:

• zfs или btrfs идеален — snapshots, compression, dedup, send/receive.
• Если только Linux — btrfs. Если рассматриваете FreeBSD — zfs.

Видеосервер (большие файлы):

• xfs — именно его use case. Большие файлы, sequential I/O.

Workstation / desktop:

• ext4 — default Ubuntu, работает out of box.
• btrfs (Fedora default) — если хочется snapshots для system rollback.

Embedded / IoT:

• ext4 с journalling или f2f s (Flash-Friendly File System) для SSD/SD card wear leveling.

Кэширование и журналирование

Все рассмотренные FS используют различные стратегии для надёжности и скорости:

CoW (Copy-on-Write) более elegant и безопасен — никогда нет состояния «частично записанного блока». Но он создаёт write amplification и фрагментацию для random writes (актуально для DB).

Попробуй сам

Попробуйте создать разные ФС на test-image:

# Создать 200 МБ image:
dd if=/dev/zero of=/tmp/test.img bs=1M count=200

# Попробовать ext4:
sudo mkfs.ext4 /tmp/test.img
sudo mkdir -p /mnt/test
sudo mount -o loop /tmp/test.img /mnt/test
df -h /mnt/test
df -i /mnt/test   # Видно фиксированное количество inodes

# Размонтировать, форматировать xfs:
sudo umount /mnt/test
sudo mkfs.xfs -f /tmp/test.img
sudo mount -o loop /tmp/test.img /mnt/test
df -i /mnt/test   # Для xfs IUsed=N/A или растёт по мере создания

# Создать btrfs:
sudo umount /mnt/test
sudo mkfs.btrfs -f /tmp/test.img
sudo mount -o loop /tmp/test.img /mnt/test
sudo btrfs filesystem df /mnt/test   # btrfs-специфичная команда

# Сделать snapshot:
sudo btrfs subvolume create /mnt/test/sv
echo "data" | sudo tee /mnt/test/sv/file
sudo btrfs subvolume snapshot /mnt/test/sv /mnt/test/snap1
ls /mnt/test/snap1   # видим файл

# Cleanup:
sudo umount /mnt/test
rm /tmp/test.img