Зачем разные ФС
Файловая система решает: как разложить блоки block-devices по inode'ам, как искать файлы по имени, как быть с crash-recovery, параллельностью, fragmentation. Разные приоритеты → разные ФС.
ext4 - рабочая лошадь
- Default на большинстве Linux-дистро
- Journaling (защита от crash'а во время записи)
- До 1 EiB ФС, 16 TiB файлов
- Хорошо изучен, стабилен 15+ лет
- Минусы: число inode фиксируется при создании; нет нативных снапшотов; ограничен parallelism для большой нагрузки
bash
sudo mkfs.ext4 /dev/sdb1
sudo mkfs.ext4 -L data -m 1 /dev/sdb1 # label "data", reserve 1% (вместо default 5%)
sudo tune2fs -l /dev/sdb1 # параметры existing ФС
sudo e2fsck -f /dev/sdb1 # проверить (только на размонтированной!)
sudo resize2fs /dev/sdb1 # подогнать под размер раздела (после parted)
xfs - для больших и параллельных нагрузок
- Default на RHEL/CentOS 7+, частый выбор для БД, файловых серверов
- Прекрасно масштабируется на множество CPU и больших файлах
- До 8 EiB
- Минусы: нельзя уменьшить размер ФС (только grow); тяжелее восстанавливать при corruption
bash
sudo mkfs.xfs /dev/sdb1
sudo mkfs.xfs -f -L data /dev/sdb1 # -f: force overwrite
sudo xfs_info /mnt/data # параметры
sudo xfs_growfs /mnt/data # увеличить (grow only!)
btrfs - copy-on-write
- Снапшоты (как у ZFS), subvolumes, нативный RAID 0/1/10
- Чексуммы данных и метаданных - обнаружение bit rot
- Минусы: RAID 5/6 исторически нестабилен; complex; на high-write нагрузках может фрагментироваться; recovery сложнее ext4
bash
sudo mkfs.btrfs -L data /dev/sdb1
sudo btrfs subvolume create /mnt/data/snap-base
sudo btrfs subvolume snapshot /mnt/data/work /mnt/data/snap-2024-01
sudo btrfs balance start /mnt/data # перераспределить блоки
zfs - самый продвинутый, не в mainline kernel
- Чексуммы, COW, снапшоты, send/receive, дедупликация, нативный RAID-Z
- Защита от bit rot уровня enterprise SAN
- Минусы: в mainline kernel'е НЕТ (CDDL+GPL конфликт); ставится отдельно (zfsonlinux); жадная до RAM (ARC-cache); меньше распространён
- Главный пользователь: TrueNAS, Proxmox, многие storage-серверы
Какую выбрать
| Use case | Рекомендация |
|---|---|
| Server root, обычные файлы | ext4 |
| БД, virt-диски, parallel I/O | xfs |
| Домашний NAS со снапшотами | btrfs или zfs |
| Backup-таргет с дедупликацией | zfs |
| Ephemeral container layer | overlay (поверх ext4/xfs) |
| Embedded / маленькие FS | f2fs (NAND-aware) |
Tmpfs / overlay / proc / sysfs - псевдо-ФС
Не все ФС лежат на диске:
- tmpfs - в RAM (
/tmp,/run,/dev/shm) - proc -
/proc- интерфейс к ядру и process-and-pid - sysfs -
/sys- интерфейс к device tree и драйверам - devtmpfs -
/dev- динамические device-nodes - overlay - слои Docker images (lower + upper = merged view)
- fuse - userspace ФС (sshfs, cephfs, любые свои)
Журналирование
Когда крашнулась запись, журнал помогает восстановиться:
- ext4 - журналит метаданные (default
data=ordered);data=journal= и данные тоже (медленнее, безопаснее) - xfs - log в отдельной области, можно вынести на отдельный диск (
-l logdev=...) - btrfs/zfs - COW = журнал не нужен в традиционном виде
Проверка целостности
bash
sudo umount /mnt/data # ВСЕГДА размонтировать перед fsck
sudo fsck -f /dev/sdb1 # ext-семейство
sudo xfs_repair /dev/sdb1 # XFS (только в crash-режиме; на здоровой ФС no-op)
sudo btrfs check /dev/sdb1 # btrfs (только diagnostics, не правит)
sudo btrfs scrub start /mnt/data # btrfs: пройти все данные, проверить чексуммы