Короткий ответ

Сообщения EXT4-fs error после жёсткого выключения не равны «немедленно e2fsck -y». Сначала: том смонтирован или нет, есть ли I/O error устройства, есть ли backup/snapshot. Журнал ext4 часто сам доигрывает replay при mount. fsck нужен, когда replay невозможен, суперблок сомнителен, или e2fsck -n (только чтение) показывает несвязные inode. Запуск fsck -y на примонтированном корне — способ получить хуже, чем было.

Хост host.example, диск-пример /dev/vda2. Пользователь admin для SSH после возврата.

Симптомы и как отличить

  • dmesg: EXT4-fs error (device vda2): ext4_lookup: deleted inode referenced;
  • boot: Unexpected inconsistency; run fsck manually;
  • том в ro — сначала read-only;
  • inode table странности при свободном месте — пересечение с inode.
Ситуацияfsck сейчас?
Чистое unmount, просто warning в старом логенет
Живой I/O error дисканет, сначала диск
Offline том, -n показывает errorsда, после копии
Смонтированный /нет

Возможные причины

  1. Power loss / Reset без umount.
  2. Snapshot freeze оборвался.
  3. Реальный bad block — fsck не лечит железо.
  4. Двойной mount одного LV (два узла, забытый iSCSI).
  5. Обрезанный qcow2/thin.

Диагностика

dmesg -T | grep -iE 'ext4|jbd2|fsck' | tail -n 60
journalctl -k -b -1 --no-pager | grep -i ext4 | tail
tune2fs -l /dev/vda2 | grep -E 'Filesystem state|Last mount|Last write|Errors|Journal|Free blocks|Free inodes'
findmnt /dev/vda2

Filesystem state: clean после успешного replay. not clean — не umounted.

Только проверка без изменений (том не должен быть rw-mounted; для корня — live ISO):

sudo umount /data
sudo e2fsck -n /dev/vda3

Коды выхода e2fsck: 0 чисто, 1 ошибки исправлены (в -n это «были бы»), ≥4 нужна операторская работа. Читайте man.

Суперблок backup, если основной не читается:

sudo dumpe2fs /dev/vda2 | grep -i 'superblock'
# не применяйте -b, пока не зафиксирован вывод -n и копия

SMART/диск:

sudo smartctl -a /dev/sda | egrep 'SMART overall|Reallocated|Pending|Uncorrect'

Если диск сыплет UNC — клонируйте ddrescue, не бесконечный fsck.

Решение

Сценарий A. Replay журнала достаточен

Том umounted, e2fsck -n почти чистый, state not clean. Монтирование само проиграет journal. После mount:

sudo mount /data
dmesg -T | tail

Нет новых EXT4-fs error — не гоните -y.

Сценарий B. Нужен fsck на data-томе

sudo systemctl stop app.service
sudo umount /data
sudo e2fsck -f -p /dev/vda3

-p безопаснее слепого -y для «автоисправимых» ошибок; если e2fsck откажется — остановитесь и читайте, не переходите сразу к -y.

Сценарий C. Корень

Live ISO той же Ubuntu 22.04/24.04, не fsck из emergency на полупримонтированном /. В live:

sudo e2fsck -n /dev/vda2
# после backup:
sudo e2fsck -f -p /dev/vda2

Затем загрузка.

Сценарий D. lost+found полон

Это не «восстановление имён». Файлы без пути. Копируйте наружу, не оставляйте прод на lost+found.

Сценарий E. Суперблок

Только если dumpe2fs основного падает, а диск читается:

sudo e2fsck -n -b 32768 /dev/vda2

Число 32768 — пример из dumpe2fs этого тома, не универсальная магия.

Оценка риска: когда остановиться и клонировать диск

e2fsck -n пишет «would fix» без изменений, но на умирающем диске даже чтение journal усиливает сбой. Если smartctl показывает растущий Pending/UNC или dmesg сыплет medium error каждые секунды — сначала ddrescue на новый диск, fsck уже копии.

Порядок:

  1. Снимок VM или ddrescue в файл на другом datastore.
  2. e2fsck -n на копии.
  3. Решение: mount копии read-only и забрать файлы vs e2fsck -p на копии.
  4. Прод-диск не трогать, пока копия не подтверждена.

debugfs -R 'stat <inode>' полезен точечно; не debugfs -w на проде.

После жёсткого Reset journal replay при mount может занять минуты на большом томе — это не hang. Смотрите dmesg recovery complete. Прерывать reboot'ом — заново рвать journal.

Флаг needs_recovery в tune2fs -l после чистого umount должен исчезнуть. Если остаётся — том всё ещё кто-то держит или journal не дописан.

Счётчик монтирований и fsck interval в tune2fs -l (Maximum mount count, Check interval) заставляет systemd-fsck запускаться на boot. Это не доказательство повреждения. Если каждый reboot просит manual fsck — либо ФС реально dirty, либо кто-то ставит fsck.mode=force в cmdline. Снимите cat /proc/cmdline после входа.

Не копируйте backup superblock offsets из чужой статьи: они зависят от размера тома и mkfs options. Только dumpe2fs этого /dev/vda2.

Как проверить, что проблема устранена

tune2fs -l /dev/vda2 | grep 'Filesystem state'
dmesg -T | grep -i ext4 | tail
findmnt /
df -h
sudo e2fsck -n /dev/vda3

Приложения читают свои данные (хеш дампа БД, список файлов). Новые error в journal за час нагрузки не появляются.

Если не помогло

  • error сразу после fsck: железо, клонируйте том.
  • Цикл fsck на каждой загрузке: tune2fs -C/-i не вместо ремонта; смотрите, кто пишет в том с двух VM.
  • XFS вперемешку: это не e2fsck.

Профилактика

  • Корректный shutdown, UPS, запрет Reset «потому что медленно».
  • Журнал ext4 (data=ordered по умолчанию) не отключать.
  • Регулярный backup файлов, не надежда на journal.
  • Не подключать один и тот же raw disk к двум запущенным VM.

FAQ

fsck.mode=force в GRUB?

Принудительная проверка корня на каждом старте. Для разовой диагностики с live лучше. Force на умирающем диске вреден.

Чем -p отличается от -y?

-p (preen) чинит только очевидно безопасное; на серьёзных вопросах выходит с ошибкой. -y отвечает да на всё.

Можно ли fsck LVM snapshot?

Да, и это хороший приём: fsck снапшота, прод работает. Нужно место COW.

journal ext4 «сломан»

Без журнала e2fsck тяжелее. Не обнуляйте journal командами с форумов.

После fsck пропали файлы

Ожидаемый риск -y. Ищите в lost+found и в backup. Не запускайте повторный -y «ещё раз».