ext4 vs XFS для веб‑нагрузки: что выбрать на VDS и какие параметры включить

Какая файловая система лучше подходит для веб‑нагрузки на VDS — ext4 или XFS? Спойлер: универсального ответа нет. Но если аккуратно разложить типы нагрузки, особенности журналирования и параметры монтирования, можно получить конфигурацию, которая даёт предсказуемую производительность и не бьёт по надёжности. Если вы только планируете инфраструктуру, посмотрите также, как выбрать конфигурацию VDS по CPU/RAM/диску.

Веб‑нагрузка: что именно мы ускоряем

Под «веб‑нагрузкой» на практике обычно скрываются такие шаблоны:

• Множество мелких файлов (PHP, шаблоны, ассеты, кэш фреймворков), преимущественно чтение.
• Последовательная запись логов (nginx, PHP‑FPM, приложений), ротация.
• Смешанная активность в каталогах с большим количеством объектов (uploads, thumbnails).
• Контейнеры/оркестрация (Docker/Podman) с требованиями к атрибутам каталога и копированию слоёв.
• Бэкапы, развёртывания, атомарные обновления (много операций rename, fsync, массовые метаданные).

Базы данных лучше держать отдельно и настраивать исходя из их профиля. Здесь фокус именно на файловой системе для кода, статики, логов и контейнеров.

ext4 и XFS: сильные стороны

Когда ext4 проще и надёжнее выбора

• Стабильность и предсказуемость под смешанную нагрузку, невысокий накладной расход на метаданные.
• Отлично справляется с множеством мелких файлов и умеренным уровнем параллелизма.
• Широкая экосистема инструментов (e2fsck, tune2fs), привычные политики восстановления.
• На небольших VDS (мало RAM и CPU) часто показывает себя более «экономно».

Когда XFS раскрывается лучше

• Высокий параллелизм и крупные каталоги: развитая аллокация по группам, масштабируемые метаданные.
• Удобные проектные квоты и управление ими, зрелые инструменты.
• Поддержка reflink (копирование‑на‑запись) — быстрое клонирование больших деревьев (стейджинг, бэкапы).
• Хорошая производительность на NVMe под потоковую запись и интенсивные операции с каталогами.

В реальности на одном и том же NVMe‑VDS разница между ext4 и XFS в «средних» кейсах может быть невелика. Выбор заметнее с ростом параллелизма, размеров каталогов и требований к операциям с метаданными.

Журналирование и безопасность данных

Обе файловые системы ведут журнал метаданных. У ext4 режим по умолчанию data=ordered: перед фиксацией метаданных на диск гарантируется запись связанных с ними данных, что снижает риск «мусора» в файлах после сбоев. Режим data=writeback быстрее, но менее безопасен (обычно не рекомендуется для веб‑корней).

У XFS журнал метаданных всегда включён. На современных ядрах управление барьерами и flush‑операциями делается автоматически; отключать защитные механизмы (исторические nobarrier) без аппаратной гарантии (BBU/PLP) не стоит.

Для PROD окружений сохраняйте безопасные настройки журналирования. Экономия на «барьерах» часто заканчивается потерей данных после внезапной перезагрузки.

Опции монтирования для веб‑нагрузки

Опции, которые почти всегда уместны

• noatime — отключает обновление времени доступа, снижает лишние записи. На современных системах по умолчанию relatime, но для веб обычно смело используем noatime.
• lazytime — откладывает запись временных меток на диск, объединяя обновления. Хороший компромисс между корректностью и I/O.
• TRIM/Discard — вместо постоянного discard используйте периодический fstrim таймер, чтобы не добавлять латентность каждому удалению.

systemctl enable fstrim.timer
systemctl start fstrim.timer

• Квоты — если есть мультиарендность (несколько проектов/сайтов), включайте проектные квоты (prjquota) для изоляции диска по каталогам.

ext4: рекомендуемые опции

• noatime,lazytime — базовая экономия I/O.
• commit=30 или commit=60 — увеличивает интервал коммита журнала (секунды), немного снижая накладные расходы. Чуть повышает риск потери последних секунд метаданных при аварии.
• errors=remount-ro — предсказуемое поведение в авариях.
• prjquota — для проектных квот (по каталогам).

# /etc/fstab (пример)
UUID=xxxx-xxxx /var/www ext4 noatime,lazytime,commit=60,errors=remount-ro,prjquota 0 2

Дополнительно: на новых ядрах ext4 поддерживает fast_commit (ускорение fsync/rename паттернов). Если ФС создавалась недавно современными утилитами, фича, как правило, включена автоматически.

XFS: рекомендуемые опции

• noatime,lazytime — базовые оптимизации.
• inode64 — обычно включён по умолчанию; разрешает размещать иноды по всему адресному пространству, помогает фрагментации.
• prjquota — проектные квоты с удобными инструментами.

# /etc/fstab (пример)
UUID=yyyy-yyyy /var/www xfs noatime,lazytime,inode64,prjquota 0 0

Исторические параметры вроде logbufs/logbsize на современных ядрах часто игнорируются или подбираются автоматически. Настраивайте их точечно после профилирования.

Создание ФС (mkfs) под веб

ext4: практичные пресеты

• Включаем современные фичи: контрольные суммы метаданных, 64‑битные группы, dir_index уже по умолчанию.
• Уменьшаем резерв под root до 0–1% на больших разделах.
• Под мелкие файлы увеличиваем плотность инодов.

# Создание ext4 под www
mkfs.ext4 -L www -O metadata_csum,64bit -T small -i 16384 -m 1 /dev/vdb1

# Увеличить журнал, если ожидается метаданные‑heavy (ротация логов, массовые rename)
tune2fs -J size=1024 /dev/vdb1

-T small и -i 16384 дают больше инодов, что полезно для директорий с тысячами миниатюр и кэшей. Увеличенный журнал снижает частоту блокировок на метаданных под пиковую активность.

XFS: акценты при создании

• Включаем контрольные суммы и индекс свободных инодов (обычно по умолчанию).
• Активируем reflink для быстрых клонов деревьев (стейджинг/релизы).
• Для Docker обязателен ftype=1 (иначе overlay2 не работает).

# Создание XFS под www
mkfs.xfs -L www -m crc=1,finobt=1,reflink=1 -n ftype=1 -i size=256 /dev/vdb1

# Если много метаданных и высокая конкуренция — больше внутренний лог
mkfs.xfs -L www -m crc=1,finobt=1,reflink=1 -n ftype=1 -l size=1024m -i size=256 /dev/vdb1

На RAID/NVMe с полосами стоит задавать выравнивание (-d su=...,sw=...) для лучшей последовательной записи. Для одиночного виртуального диска это обычно не требуется.

Проектные квоты: изоляция диска по сайтам

Проектные квоты позволяют задать лимиты на каталог и все его подкаталоги — идеально для хостинга нескольких сайтов или окружений на одном сервере.

# Монтируем с prjquota (fstab пример был выше)
mount -o remount /var/www

# Описываем проекты
# /etc/projects
1001:/var/www/site1
1002:/var/www/site2

# /etc/projid
site1:1001
site2:1002

# Инициализация атрибутов проекта (на XFS и ext4 можно использовать xfs_quota)
xfs_quota -x -c "project -s site1" /var/www
xfs_quota -x -c "project -s site2" /var/www

# Лимиты (мягкий/жёсткий для блока и инодов)
xfs_quota -x -c "limit -p bsoft=5g bhard=6g isoft=200k ihard=220k site1" /var/www
xfs_quota -x -c "limit -p bsoft=10g bhard=12g isoft=400k ihard=450k site2" /var/www

# Проверка
xfs_quota -x -c "report -p" /var/www

Несмотря на название, утилита xfs_quota умеет работать и с ext4, если ядро и утилиты поддерживают проектные квоты. Это упрощает единый operational‑подход на разных ФС.

Docker/CI и развёртывания

Если на сервере активно используются контейнеры, XFS с ftype=1 и reflink=1 даёт ощутимые плюсы при копировании слоёв и сборках. Для ext4 критично, чтобы ФС поддерживала d_type (на современных системах это обычно так по умолчанию). В обоих случаях проверяйте требования вашего контейнерного рантайма.

Деплой через атомарные rsync --link-dest или копирование деревьев выигрывает на XFS благодаря reflink‑клонам, которые создаются почти мгновенно и не потребляют место до изменений. На ext4 такую экономию места не получить, но производительности чтения кода это не мешает.

Логи, кэш и большие каталоги

Логи — последовательная запись с периодической ротацией и компрессией. Обе ФС справляются хорошо, но XFS иногда показывает меньшую латентность под массовую ротацию при высокой конкуренции. Для каталогов с десятками-сотнями тысяч файлов XFS устойчивее по временам операций readdir/unlink под нагрузкой.

Кеши фреймворков (Symfony, Laravel, Magento) активно работают с метаданными. На малых VDS ext4 может давать более стабильную задержку из‑за меньшего накладного расхода, особенно при ограниченной памяти. На более «толстых» VDS с NVMe разница сглаживается или уходит в пользу XFS при параллельной записи.

Память и кеши ядра

Производительность веб‑сервера часто упирается не во «возможности ФС», а в эффективность page cache и dentry/inode cache. Если RAM мало, отдача статики будет одинаково упираться в диск, и преимущества той или иной ФС нивелируются. В таких случаях логично выбирать более «лёгкую» конфигурацию (часто ext4) и инвестировать в оптимизацию приложения и HTTP‑стека. Для повышения общей безопасности сервисов полезно посмотреть на усиление системных сервисов через sandboxing systemd.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Чек‑лист выбора

• Небольшой VDS с ограниченной RAM/CPU, сайты на PHP, много мелких файлов, без контейнеров — ext4 с noatime,lazytime,commit=60.
• Много параллельных деплоев, контейнеры, крупные каталоги, нужны быстрые клоны — XFS с inode64,prjquota,noatime,lazytime, создана с reflink=1 и ftype=1.
• Мультиарендность — в обеих ФС включайте prjquota и ведите лимиты через xfs_quota.
• TRIM — не discard на монтировании, а fstrim.timer.
• Журнал — оставляем безопасные режимы; увеличиваем размер журнала при «метаданные‑heavy» сценариях.

Профилирование и валидация

Перед миграцией продакшена проверьте конфигурацию на стейджинге, замерьте реальные метрики: медиану и хвосты задержек (p95/p99) операций чтения/записи, время ротации логов, длительность деплоя. Используйте fio для синтетики и свои же скрипты деплоя/билда для репликатора нагрузки. Смотрите на системные метрики (iostat, vmstat, pidstat) и на отражение в пользовательских метриках (время ответа веб‑приложения, таймауты PHP‑FPM, скорость генерации кэша). Если нужен чистый сервер под эксперименты — поднимите VDS и тестируйте конфигурации из статьи.

Итог

Для типичной веб‑нагрузки на VDS обе системы подходят. Если у вас небольшой сервер и преобладает чтение множества мелких файлов — ext4 даст простую и предсказуемую конфигурацию. Если нагрузка параллельная, каталоги крупные, используются контейнеры и нужны быстрые клоны деревьев — XFS окажется практичнее за счёт масштабируемых метаданных и reflink. В обоих случаях не забывайте про noatime, lazytime, проектные квоты и периодический fstrim, а также подбирайте размер журнала под ваши пики метаданных. Главный критерий — ваши реальные метрики под вашей нагрузкой.