Сколько длится fsck на 10 терабайтах: замер, который стоит сделать до аварии

MAATRIX

Сервер перезагрузился не так, как надо — питание моргнуло, гипервизор убил виртуалку по таймауту, ядро упало в панику — и вместо привычных секунд загрузки вы смотрите на строку fsck в консоли, которая не двигается уже двадцать минут. На 10 терабайтах непонятно, это займёт ещё пять минут или ещё пять часов, а сервис тем временем не отвечает. Разберём, от чего реально зависит время проверки файловой системы после сбоя, чем в этом смысле отличаются ext4, XFS и ZFS, и как получить свою собственную оценку времени заранее — до того, как это придётся выяснять посреди аварии.

Когда fsck вообще запускается и почему это не пустая формальность

После некорректного завершения работы (потеря питания, kill -9 гипервизором, паника ядра, аппаратный сбой RAID-контроллера) файловая система на диске может остаться в промежуточном состоянии: часть метаданных записана, часть — нет. У современных журналируемых ФС для этого есть штатный механизм: при монтировании ядро видит незавершённую транзакцию в журнале и проигрывает её (replay) — досчитывает то, что было прервано. Это быстрая операция, обычно секунды, максимум минуты, и она проходит незаметно при обычной загрузке.

Полная проверка (e2fsck -f, xfs_repair без -n в режиме реального ремонта) — это другое: полный обход всей структуры метаданных, а не доигрывание последней транзакции. Она запускается, когда:

• журнал сам оказался повреждён или не может быть чисто проигран (это уже не «прерванная запись», а реальное расхождение в метаданных);
• сработал периодический счётчик проверок — по числу монтирований или по времени с последней проверки (tune2fs -l покажет Maximum mount count и Check interval; на многих облачных образах эти счётчики по умолчанию отключены — tune2fs -c 0 -i 0, но об этом важно знать заранее, а не удивляться при следующей перезагрузке);
• проверка запущена вручную, потому что диск/сервис ведёт себя странно и есть подозрение на порчу данных.

Опасность не в самой проверке, а в моменте, когда она случается: production лежит, и на восстановление накладывается процесс с непредсказуемой длительностью. Отдельная граблина — таймаут systemd на монтирование: юнит systemd-fsck@.service ждёт завершения проверки ограниченное время (регулируется опцией монтирования x-systemd.device-timeout в /etc/fstab или systemd.default_timeout_start_sec), и если fsck на большом томе не укладывается в дефолтный интервал, сервер может свалиться в emergency shell вместо того, чтобы просто подождать — downtime увеличивается не из-за самой проверки, а из-за того, что об этом лимите не подумали заранее.

От чего реально зависит время проверки

Самое частое заблуждение: «10 терабайт — значит, долго». На практике время fsck куда сильнее коррелирует с числом объектов метаданных (inode, записей в каталогах, блоков в битовых картах), чем с объёмом самих данных в байтах. e2fsck и аналоги не читают содержимое файлов — они обходят таблицу inode, битовые карты блоков и структуру каталогов, сверяя ссылки и счётчики. Эта работа масштабируется по числу объектов, а не по гигабайтам полезной нагрузки.

Отсюда вывод, который часто ломает интуицию: том на 10 ТБ с полусотней больших файлов (архив видео, образы бэкапов) проверяется быстро — метаданных там немного. А том на 2 ТБ с двумя сотнями миллионов мелких файлов (почтовый спул, объектное хранилище на файловой системе, артефакты сборки) может проверяться заметно дольше — потому что структуре нужно обойти каждый inode и каждую запись в каталоге. Подробнее о том, почему именно число файлов, а не их суммарный объём, определяет нагрузку на файловую систему — в статье про то, как миллион мелких файлов убивает диск и в разборе того, что такое inode и почему место есть, а файл не создаётся.

Ключевые факторы, от которых реально зависит время полной проверки:

Практический вывод: перед тем как пугаться цифры «10 ТБ», посмотрите на df -i — сколько inode реально используется. Том с 5 миллионами занятых inode и том с 500 миллионами при одинаковом объёме в байтах — это совершенно разные по времени проверки задачи.

ext4: журнал спасает от быстрого fsck, но не всегда

По умолчанию ext4 работает в режиме журналирования ordered — метаданные (а при необходимости и данные) фиксируются в журнале перед применением. После сбоя ядро при монтировании проигрывает журнал — это и есть тот самый быстрый автоматический recovery, который в норме проходит за секунды и не требует полного e2fsck -f. Именно журнал — причина, почему подавляющее большинство перезагрузок после сбоя не превращаются в многочасовое ожидание. О том, что журнал реально спасает, а что нет, подробно — в статье журнал файловой системы: что он не спасает: он защищает консистентность метаданных, но не гарантирует сохранность недописанных данных приложения и не заменяет полную проверку в случаях реальной порчи структуры.

Полная e2fsck -f нужна, когда журнал не может быть чисто проигран (расхождение глубже, чем прерванная транзакция), либо когда её запускает периодический счётчик, либо вручную — при подозрении на повреждение. Проверить и настроить периодичность:

tune2fs -l /dev/sdX | grep -iE "mount count|check interval"
tune2fs -c 30 -i 0 /dev/sdX   # проверка раз в 30 монтирований, без привязки по времени
tune2fs -c 0 -i 0 /dev/sdX    # отключить автоматическую периодическую проверку полностью

Полностью отключать периодические проверки — соблазнительно (не будет сюрприза при случайной перезагрузке), но у этого есть цена: пропадает штатный механизм, который иногда ловит тихо накапливающуюся порчу метаданных раньше, чем она станет серьёзной проблемой. Практичнее — не отключать совсем, а перенести проверку из «случайно посреди инцидента» в плановое окно обслуживания, где вы сами выбираете время и готовы к простою.

Для замера без риска что-либо испортить используется режим только для чтения:

e2fsck -fn /dev/sdX     # dry-run: показывает, что было бы исправлено, ничего не пишет
e2fsck -C0 -f /dev/sdX  # реальный проход с индикатором прогресса (полезно понимать, сколько ещё осталось)

XFS: другой подход к журналу и восстановлению

У XFS журнал (log) устроен иначе — он метаданных-ориентированный и спроектирован так, чтобы восстановление после сбоя (log recovery) было быстрым и происходило автоматически при монтировании, без вмешательства администратора — концептуально это тот же принцип, что и журнал ext4, но реализация и внутренние структуры другие. XFS исторически не строилась вокруг идеи периодической принудительной полной проверки по счётчику монтирований — философия ближе к «журнал сам восстанавливает консистентность после обычного сбоя, а полный ремонт — отдельная ручная операция для случаев реальной порчи».

Аналог e2fsck -f для XFS — утилита xfs_repair, и она не встроена в автоматический процесс загрузки: её запускают вручную, когда есть основания подозревать повреждение (ошибки в dmesg, отказ смонтировать том, предупреждения от xfs_info). У xfs_repair есть особенность, о которой стоит знать заранее: по опыту администраторов, работающих с большими и повреждёнными XFS-томами, процесс может требовать заметно больше оперативной памяти, чем ext4-эквивалент — на этапе построения дерева метаданных в памяти для сильно фрагментированных или объёмных структур каталогов. Если планируете XFS на большом томе, закладывайте RAM с запасом именно под сценарий ремонта, а не только под обычную нагрузку.

Проверка без изменений:

xfs_repair -n /dev/sdX

Важный нюанс: в отличие от journal replay при монтировании, xfs_repair в режиме реального ремонта требует размонтированного (или как минимум read-only смонтированного) тома — то есть это плановая offline-операция, а не то, что происходит незаметно при обычной загрузке.

ZFS: почему там нет классического fsck

В ZFS структурно нет утилиты, аналогичной e2fsck или xfs_repair, и причина в архитектуре, а не в недосмотре. ZFS — copy-on-write файловая система: она никогда не перезаписывает живые структуры метаданных на месте. Изменение записывается в новые блоки, и только после того как новые данные надёжно легли на диск, атомарно переключается указатель на новый корень дерева (uberblock). Из этого следует, что на диске в любой момент времени существует полностью консистентное состояние — либо старое, либо новое, но никогда «наполовину записанное». Сбой питания посреди операции просто откатывает состояние к последнему целому snapshot дерева, без обхода и починки структуры при следующем монтировании.

Второй элемент — контрольные суммы на всех блоках данных и метаданных (не только на метаданных, как в некоторых других ФС), и самовосстановление при наличии избыточности (mirror, raidz): если контрольная сумма блока не совпала, а есть резервная копия, ZFS чинит блок автоматически и незаметно для приложения. zpool scrub читает и проверяет все данные пула против контрольных сумм — но это решает другую задачу (поиск тихой порчи данных, bit rot, за долгий период), не проверку консистентности после сбоя, и что важно — scrub идёт в фоне на смонтированном и рабочем пуле, а не блокирует загрузку сервиса.

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

Как оценить время fsck для своей системы и что сделать заранее

Готовых цифр «столько-то минут на терабайт» не существует в осмысленном виде — слишком много переменных (число inode, объём RAM, тип носителя, состояние массива), и чужой бенчмарк с чужим распределением файлов и чужим железом ничего не скажет о вашей системе. Единственный надёжный способ — измерить на своих данных:

1. Посмотрите реальное число используемых inode: df -i /mnt/data. Это даст порядок величины задачи лучше, чем объём в терабайтах.
2. Возьмите реалистичную копию — снапшот LVM, клон ZFS/Btrfs или восстановленный бэкап на тестовый том со сравнимым числом и распределением файлов по размеру. Это должна быть копия близкая к продакшену по числу объектов, а не пустой том того же объёма.
3. Отмонтируйте тестовый том и прогоните dry-run с замером времени:

time e2fsck -fn /dev/testvol
# или
time xfs_repair -n /dev/testvol

1. Проводите замер на железе, сопоставимом с продакшеном по RAM и типу диска — на более мощном dev-ноутбуке цифра будет обманчиво оптимистичной, а именно RAM — один из главных множителей.
2. Повторяйте замер по мере роста данных — число файлов растёт со временем, и цифра полугодовой давности может не отражать текущую реальность.
3. Отдельно проверьте сценарий восстановления в реальном окружении аварии: если спасательная (rescue) среда или загрузочный образ хостера даёт меньше памяти, чем боевая ОС, проверка в реальной аварии может оказаться заметно медленнее вашего теста.

Полученную цифру стоит закладывать не только в личные ожидания, но и в runbook и в переговоры про допустимый простой — если у вас в договоре есть формальные обязательства по доступности, отсутствие информации о худшем сценарии fsck обычно и оборачивается тем часом простоя, который потом трудно объяснить; про то, во что реально обходится час простоя, — в статье про час простоя SaaS: потери, отток и штрафы по SLA.

Из измеренной цифры вытекают и практические меры снижения риска: не держать один гигантский том на 10 ТБ под всё подряд, а делить хранилище по назначению — так порча метаданных в одной части не заставляет проверять всё остальное; переносить полные проверки из «случайно при перезагрузке» в плановые окна; ставить ИБП и не полагаться на то, что сбой питания — редкость; и на новых развёртываниях осознанно выбирать файловую систему под профиль нагрузки, а не по умолчанию — сравнение подходов ext4, XFS, ZFS и Btrfs — в статье ext4, XFS, ZFS, Btrfs: как выбрать.

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