SSD‑гигиена на VDS: fstrim, discard и безопасные опции монтирования

SSD‑гигиена — это набор практик, которые уменьшают запись «лишних» данных, поддерживают внутреннюю уборку SSD (TRIM) и защищают файловую систему от рискованных настроек. На VDS это критично: вы делите гипервизор с соседями, а значит любая просадка IO мгновенно отражается на времени отклика приложений и базе данных.

Почему SSD‑гигиена важна именно на VDS

SSD постепенно теряют производительность при длительной эксплуатации без TRIM: ячейки заполняются «мусором», контроллеру сложнее находить свободные блоки, растёт write amplification и латентность записи. Виртуализация добавляет свои слои (виртуальные диски, LVM, шифрование), и не каждый слой по умолчанию корректно пропускает TRIM.

Правильно настроенный TRIM и безопасные mount options для ext4/XFS помогают:

• сдерживать деградацию производительности;
• уменьшать объём лишних записей на SSD;
• избегать рискованных настроек журналирования и барьеров;
• снижать нагрузку на IO в часы пиков.

TRIM — это подсказка накопителю, какие блоки можно считать свободными. На VDS она должна пройти через все слои: файловая система → LUKS/dm‑crypt → LVM → виртуальный диск → физический SSD.

fstrim против discard: что выбрать

Есть два подхода к TRIM:

• fstrim — периодическая пакетная очистка свободных блоков. Запуск вручную или через планировщик (fstrim.timer).
• discard (опция монтирования) — отправляет TRIM при освобождении блоков (удалении файлов). Это может давать постоянные дополнительные IO‑операции.

Практическая рекомендация для большинства VDS: используйте периодический fstrim через systemd‑таймер. Он выполняется в «окно» и не дробит вашу нагрузку мелкими TRIM‑запросами. Опцию монтирования discard включайте только после измерений, а для ext4 предпочтительно discard=async (если поддерживается вашим ядром), чтобы снизить синхронный оверхед.

Проверяем поддержку TRIM виртуальным диском

Сначала убедитесь, что ваш виртуальный диск вообще умеет TRIM/UNMAP:

lsblk -D
lsblk -o NAME,DISC-MAX,DISC-GRAN,DISC-ALN,ROTA
cat /sys/block/vda/queue/discard_max_bytes
cat /sys/block/vda/queue/discard_granularity

Если значения discard_max_bytes и discard_granularity нулевые, TRIM «не проходит» на этом уровне. На некоторых платформах TRIM доступен только для определённых типов виртуальных дисков или шины (virtio‑blk, virtio‑scsi). Если TRIM поддерживается, можно переходить к настройке.

Если вы недавно расширяли диск или раздел, проверьте корректность работы после growpart и ресайза файловой системы — поможет разбор в материале «Увеличение диска VDS и growpart» по шагам: корректное расширение диска и раздела.

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

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды Финляндия

Смотреть тарифы

Включаем безопасный по умолчанию: fstrim.timer

Современные дистрибутивы уже поставляют fstrim.timer. Проверьте и включите его:

systemctl status fstrim.timer
sudo systemctl enable --now fstrim.timer
systemctl list-timers | grep fstrim

Запустить принудительно для всех смонтированных файловых систем:

sudo fstrim -av

Посмотреть отчёт и длительность в журнале:

journalctl -u fstrim --no-pager -n 50

По умолчанию таймер запускается еженедельно. Если есть узкое ночное окно, можно переопределить расписание:

sudo systemctl edit fstrim.timer

И задать, например, каждую ночь в 03:10:

[Timer]  03:10:00
RandomizedDelaySec=20m

RandomizedDelaySec слегка рандомизирует старт, чтобы не «стрелять» точь‑в‑точь в одну минуту.

Когда уместен discard в опциях монтирования

Опция discard заставляет файловую систему отправлять TRIM при освобождении блоков. На загруженных системах это может добавлять заметный оверхед. Исключение — банки с большим постоянным churn объёмов (например, CI‑агенты, кэши, очень частые удаления), где аккуратный фоновый TRIM даёт более равномерный IO.

Нюансы по файловым системам:

• ext4: начиная с новых ядер доступен discard=async, который выполняет TRIM асинхронно и снижает задержки. Для старых ядер discard может быть дорог.
• XFS: поддерживает discard, но варианта discard=async нет. На нагруженных VDS зачастую лучше оставить периодический fstrim.

Итого: по умолчанию — fstrim.timer. Включайте discard (на ext4 желательно discard=async) только после замеров на вашем профиле нагрузки.

Безопасные и практичные mount options для SSD (ext4/XFS)

Доступные всем: relatime и lazytime

relatime — дефолт в современных ядрах; он существенно сокращает записи atime без полного отключения. noatime убирает записи ещё сильнее, но может ломать редкие приложения, зависящие от atime. Золотая середина — relatime.

lazytime — откладывает обновление временных меток на диск, сбрасывая их при синхронизациях/барьерах. Это уменьшает количество мелких записей на SSD без рисков, присущих устаревшему noatime. Поддерживается большинством актуальных ядер и файловых систем.

ext4: что стоит и не стоит трогать

• data=ordered — режим журналирования по умолчанию; держите его. writeback быстрее в синтетике, но опаснее для приложений.
• barrier/nobarrier — не отключайте барьеры на VDS. Это риск потери данных при сбоях.
• commit=60 — разумный компромисс между количеством сбросов и окном потенциальной потери данных (в секундах). Для активных БД можно 30, для статики — 120.
• discard — только после измерений; если ядро поддерживает, используйте discard=async.

XFS: лог структурирован, но будьте осторожны с discard

• attr2 и другие параметры обычно включены по умолчанию; оставляйте дефолт.
• relatime и lazytime — безопасные опции для уменьшения количества записей.
• discard может давать стабильный фон нагрузки; чаще предпочтителен fstrim.timer.

Больше практики по журналированию и параметрам для конкретных профилей нагрузки смотрите в разборе «Тюнинг ext4/XFS на VDS»: расширенный тюнинг файловых систем.

Примеры настроек /etc/fstab

ext4 с периодическим fstrim, без постоянного discard:

/dev/vda1  /      ext4  defaults,relatime,lazytime,commit=60  0 1

ext4 с осторожным включением discard=async (если поддерживается ядром):

/dev/vda1  /      ext4  defaults,relatime,lazytime,commit=60,discard=async  0 1

XFS с безопасными опциями:

/dev/vda1  /      xfs   defaults,relatime,lazytime  0 0

Снижение износа SSD за счёт выноса временных файлов в RAM (опционально):

tmpfs      /tmp   tmpfs rw,nosuid,nodev,noexec,mode=1777,size=1G  0 0

Учтите, что некоторые сборки и инструменты могут требовать исполнение во временных каталогах. В таких редких случаях отключите noexec на время задачи или используйте отдельный рабочий каталог.

Проверяем, что TRIM реально работает

Разовый прогон увидит, сколько освобождено:

sudo fstrim -v /
sudo fstrim -v /var

TRIM доступен на устройстве, если значения в lsblk -D не нулевые, а fstrim не ругается на Operation not supported. Также полезно убедиться, что таймер срабатывает:

journalctl -u fstrim --since "-30 days" --no-pager

LUKS/dm‑crypt и LVM: как пропустить TRIM через слои

Если раздел зашифрован через LUKS, TRIM по умолчанию заблокирован. Его нужно явно разрешить в /etc/crypttab опцией discard (это эквивалент --allow-discards):

cryptroot UUID=xxxx-xxxx-... none luks,discard

После изменения перезагрузитесь или переоткройте устройство. Помните о компромиссе: TRIM раскрывает устройству, какие блоки свободны. Для большинства VDS это нормальная плата за предсказуемую производительность, но если для вас критична модель сокрытия объёма, взвесьте риски.

В LVM убедитесь, что включена пересылка TRIM вглубь стеков. В /etc/lvm/lvm.conf установите:

devices {
    issue_discards = 1
}

Это позволит LVM передавать освобождение блоков ниже, к виртуальному диску. На thin‑пулах TRIM особенно полезен, чтобы не накапливать «надутые» тома.

Наблюдаем и измеряем влияние на performance

• iostat -x 1 — расширенная статистика, видно утилизацию и средние задержки.
• iotop — какие процессы сейчас создают IO.
• time fstrim -av — оценка длительности пакетного TRIM.

Задача — добиться, чтобы TRIM запускался в низкую нагрузку и не создавал длительных «ступеней» латентности для критичных сервисов.

Частые ошибки и анти‑паттерны

• Включили discard на старом ядре ext4 и удивились росту задержек записи — переходите на discard=async (если доступен) или возвращайтесь к fstrim.timer.
• Выставили noatime, а затем обнаружили странности в софте, который полагался на atime. Лучше relatime или lazytime.
• Отключили барьеры (nobarrier) ради микроскопического выигрыша — на VDS это неоправданный риск целостности.
• Не проверили поддержку TRIM на виртуальном диске — fstrim молчит, а пользы ноль.
• Забыли разрешить TRIM в LUKS/LVM — файловая система «отправляет», но до SSD это не доходит.
• Завысили commit до сотен секунд — при сбое потеряете слишком много незаписанных метаданных.

Краткий чек‑лист по SSD‑гигиене на VDS

• Проверьте поддержку TRIM: lsblk -D, файлы в /sys/block/*/queue/.
• Включите fstrim.timer и подберите удобное расписание.
• Для ext4 рассмотрите discard=async только после замеров; для XFS чаще достаточно fstrim.
• Примените безопасные mount options: relatime, lazytime, адекватный commit, не трогайте барьеры.
• Если используется LUKS/LVM — включите проход discard в /etc/crypttab и issue_discards в LVM.
• Перенесите «шумные» временные файлы в tmpfs, если это совместимо с вашими процессами.
• Задокументируйте изменения и держите планы отката.

Лучшее правило SSD‑гигиены — регулярность и умеренность. Раз в неделю «уборка» через fstrim, аккуратные mount options и минимум рискованных тюнингов дадут стабильный и предсказуемый performance.

Итог

На VDS правильная стратегия проста: по умолчанию используйте fstrim.timer, настраивайте безопасные mount options (relatime, lazytime, разумный commit), и тщательно измеряйте перед включением постоянного discard. Не забывайте про слои LUKS/LVM. Такая SSD‑гигиена предотвратит деградацию и обеспечит устойчивый отклик сервисов без неприятных сюрпризов.