fsck и проверка файловых систем: когда и как

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

Что на самом деле делает fsck

Для ext2, ext3 и ext4 диспетчер запускает e2fsck, для FAT — fsck.fat, для exFAT — fsck.exfat, для XFS — xfs_repair. У btrfs своя логика: fsck.btrfs существует лишь для совместимости и ничего не проверяет, а реальная работа выполняется командой btrfs check.

Проверяющая программа читает суперблок, таблицы inode, карты блоков и журнал, сравнивает их между собой и предлагает исправления. Возвращаемый код — битовая маска: 0 — ошибок нет, 1 — ошибки исправлены, 2 — исправлены, требуется перезагрузка, 4 — остались неисправленные ошибки, 8 — операционная ошибка.

lsblk -f
sudo blkid /dev/nvme0n1p2
sudo file -s /dev/nvme0n1p2
findmnt /dev/nvme0n1p2

Последняя команда важнее остальных: если она что-то вывела, раздел смонтирован, и запускать проверку нельзя.

Когда проверка действительно нужна

• После внезапного отключения питания или зависания, если в журнале ядра есть ошибки файловой системы.
• При сообщениях Structure needs cleaning, corrupted или I/O error в dmesg.
• Когда файлы пропали или каталог читается частично.

Профилактический запуск «на всякий случай» раз в месяц не нужен: ext4 и XFS проверяют журнал при монтировании, а btrfs сверяет контрольные суммы при чтении. Сначала соберите диагностику:

sudo dmesg | grep -i -E 'ext4|xfs|btrfs|i/o error'
journalctl -k -b -p err --no-pager
sudo smartctl -a /dev/nvme0n1
sudo smartctl -t short /dev/nvme0n1

Если SMART показывает перераспределённые сектора или растущий счётчик Reallocated_Sector_Ct, проблема в накопителе: сначала снимают образ, а не запускают проверку.

Резервная копия — до, а не после

Проверка файловой системы — операция с записью на диск, а не только чтение. Любое исправление меняет структуру каталогов, и откатить его без копии невозможно. Если данные ценны, сделайте образ раздела (лучше с live-носителя) или хотя бы файловую копию.

sudo dd if=/dev/nvme0n1p2 of=/mnt/backup/root.img bs=4M status=progress
sudo ddrescue -d -r3 /dev/nvme0n1p2 /mnt/backup/root.img /mnt/backup/root.map
rsync -aHAX --info=progress2 /home/ /mnt/backup/home/

Для явно больного диска порядок обратный: сначала ddrescue снимает образ, потом образ проверяют и восстанавливают, а исходный диск больше не трогают.

Размонтирование и загрузка с live-носителя

Корневую файловую систему нельзя размонтировать на работающей системе. Правильный путь — загрузиться с установочного носителя Linux Mint или другого live-образа и работать оттуда. Домашний раздел или внешний диск достаточно размонтировать в обычной сессии.

sudo umount /dev/sdb1
sudo fuser -vm /mnt/data
sudo lsof +f -- /mnt/data
findmnt /dev/sdb1

Команды fuser и lsof показывают процессы, которые держат каталог; после размонтирования findmnt должен быть пуст.

Безопасный предварительный прогон — только чтение, без исправлений:

sudo e2fsck -fn /dev/sdb1
sudo e2fsck -f -v /dev/sdb1
sudo e2fsck -f -y -v /dev/sdb1

Опция -n отвечает «нет» на все вопросы и ничего не меняет — удобно, чтобы оценить масштаб. -f заставляет проверить даже «чистую» файловую систему, -y автоматически соглашается со всеми исправлениями. На живых данных -y применяют осознанно: при серьёзном повреждении автоматические ответы могут выбрать не тот вариант.

ext4: резервные суперблоки

Если основной суперблок разрушен и e2fsck не может прочитать раздел, на помощь приходят резервные копии. Их расположение подскажет dumpe2fs, а список вариантов — mke2fs -n; в режиме -n утилита только показывает параметры и ничего не создаёт.

sudo dumpe2fs /dev/sdb1 | head -40
sudo mke2fs -n /dev/sdb1
sudo e2fsck -b 32768 -f -y /dev/sdb1

Номер блока из вывода подставьте в команду e2fsck -b. Если не помогло, копируйте уцелевшие файлы, а не повторяйте запуски.

Настройки автоматических проверок ext4 хранятся в суперблоке и меняются через tune2fs:

sudo tune2fs -l /dev/sdb1 | grep -E 'Mount count|Maximum mount|Check interval|Last checked'
sudo tune2fs -c 40 /dev/sdb1
sudo tune2fs -i 6m /dev/sdb1

btrfs и XFS: отдельные правила

Для btrfs безопасная проверка — btrfs check --readonly на размонтированном разделе. Опция --repair существует, но её применяют только после резервной копии и понимания причины: инструмент может исправить дерево так, что часть данных станет недоступной. Штатная профилактика — btrfs scrub, который сверяет контрольные суммы на смонтированной системе и при наличии копии восстанавливает повреждённый блок.

sudo btrfs check --readonly /dev/sdb1
sudo btrfs scrub start -B /dev/sdb1
sudo btrfs device stats /mnt/data
sudo xfs_repair -n /dev/sdb1

XFS не любит проверку с «грязным» журналом: xfs_repair откажется работать, пока журнал не воспроизведён. Достаточно смонтировать и корректно размонтировать раздел, чтобы ядро сделало это само. Опция -L обнуляет журнал и теряет незавершённые операции — это крайняя мера.

Автоматическая проверка при загрузке

Поле pass в /etc/fstab задаёт порядок: 1 для корня, 2 для остальных локальных разделов, 0 — не проверять. За запуск отвечает systemd-fsck, результат виден в журнале.

systemctl status systemd-fsck-root.service
journalctl -b | grep -i fsck
sudo touch /forcefsck

Файл /forcefsck устарел. Надёжнее передать ядру параметры fsck.mode=force и при необходимости fsck.repair=yes через меню GRUB: нажмите e в строке загрузки, добавьте параметры в конец строки linux и загрузитесь.

Если проверка нашла ошибки в корне и не смогла исправить их автоматически, загрузка может остановиться в emergency mode: корень перемонтируют командой mount -o remount,rw / и повторяют проверку с live-носителя.

Чек-лист

• Раздел размонтирован, findmnt пуст.
• Резервная копия создана и проверена.
• Для ext4 выполнен предварительный прогон с -n.
• Для btrfs используется btrfs check --readonly, а не fsck.btrfs.
• Для XFS журнал воспроизведён штатным монтированием.
• После проверки раздел смонтирован и файлы открываются.

Итог

fsck остаётся нужным инструментом, но лишь при двух условиях: файловая система размонтирована и резервная копия уже лежит на другом носителе. Начинайте с диагностики и «сухого» прогона, выбирайте программу под тип файловой системы и не запускайте -y вслепую. Аккуратность здесь экономит не минуты, а данные.