Определение ошибок и критических состояний файловых систем и носителей

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

Все команды в заметке выполняют чтение состояния. Исправление файловых систем здесь не рассматривается.

Быстрая проверка

Определить устройства и файловые системы:

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Проверить режим монтирования:

findmnt -rn -o TARGET,SOURCE,FSTYPE,OPTIONS

Проверить заполненность:

df -hT
df -ih

Показать предупреждения и ошибки ядра текущей загрузки:

journalctl -k -b -p warning..alert --no-pager

Показать типовые ошибки хранения:

journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|critical medium|uncorrectable|blk_update_request|reset|timeout|offline device|read-only|EXT4-fs error|JBD2|XFS.*error|XFS.*corrupt|BTRFS.*error|FAT-fs error|ntfs3.*error|md.*degraded|multipath'

Проверить предыдущую загрузку:

journalctl -k -b -1 -p warning..alert --no-pager

Список доступных загрузок:

journalctl --list-boots

Уровни реакции

Критично — реагировать немедленно

Признаки:

• повторяющиеся ошибки чтения или записи;
• I/O error, Buffer I/O error, critical medium error;
• файловая система неожиданно перешла из rw в ro;
• EXT4-fs error, остановка журнала JBD2;
• XFS ... Corruption detected;
• XFS ... Filesystem has been shut down;
• BTRFS error, ошибки контрольных сумм или uncorrectable_errors;
• SMART сообщает FAILED;
• есть ожидающие или неисправимые сектора;
• NVMe выставил critical_warning;
• RAID деградирован и потерял допустимое количество устройств;
• Multipath потерял все рабочие пути;
• файловая система или thin pool заполнены на 100%.

Действия:

1. Не создавать дополнительную нагрузку.
2. Не запускать восстановление файловой системы.
3. Не выполнять длительный SMART-тест или scrub до оценки возможности копирования данных.
4. Зафиксировать журналы и состояние устройства.
5. Определить, доступны ли важные данные для чтения.
6. Перейти к отдельному сценарию сохранения данных или замены носителя.

Требует наблюдения и дополнительной проверки

Признаки:

• единичный сброс SATA, SCSI, USB или NVMe без повторения;
• ненулевой, но не растущий счётчик переназначенных секторов;
• ненулевой UDMA_CRC_Error_Count;
• единичная исправленная ошибка Btrfs;
• один неактивный путь Multipath при наличии других исправных;
• RAID выполняет штатный resync, recovery или check;
• заполнение файловой системы выше 90%;
• заполнение inode выше 90%;
• высокая температура без выхода за пределы, указанные накопителем.

Действия:

1. Проверить, повторяется ли событие.
2. Сравнить счётчики после рабочей нагрузки.
3. Проверить кабель, порт, питание или путь до СХД, если ошибка транспортная.
4. Запланировать устранение до перехода состояния в критическое.

Информационно — обычно можно пропустить

Примеры:

• обнаружение диска при загрузке;
• штатное монтирование файловой системы;
• успешное восстановление журнала после аварийного выключения;
• clean, recovery complete, если после них нет ошибок;
• исторический счётчик включений или часов работы;
• единичное сообщение о небезопасном выключении;
• ro для squashfs, iso9660, установочного образа или специально подключённой файловой системы;
• loop-устройства от образов и пакетов;
• завершённый без ошибок RAID resync;
• SMART PASSED, если одновременно отсутствуют критические атрибуты и ошибки ядра.

Проверка системного журнала

Текущая загрузка

journalctl -k -b --no-pager

Только предупреждения и ошибки:

journalctl -k -b -p warning..alert --no-pager

Предыдущая загрузка

journalctl -k -b -1 --no-pager

Это важно, если система была перезагружена после зависания или перехода файловой системы в read-only.

По конкретному устройству

Для диска:

journalctl -k -b --no-pager | grep -i 'sda'

Для NVMe:

journalctl -k -b --no-pager | grep -i 'nvme0'

Для LVM или Multipath:

journalctl -k -b --no-pager | grep -Ei 'dm-[0-9]+|mapper|multipath'

lsblk -o NAME,KNAME,PATH,TYPE,FSTYPE,MOUNTPOINTS

Критические сообщения блочного уровня

Наиболее опасные сообщения:

I/O error
Buffer I/O error
critical medium error
uncorrectable error
blk_update_request
rejecting I/O to offline device
device offline
end_request: I/O error

Они означают, что операция ввода-вывода не была выполнена нижележащим устройством или путём.

Повторяющиеся сбросы и тайм-ауты

SATA/SAS/SCSI:

hard resetting link
link is slow to respond
failed command
timing out command
DID_NO_CONNECT
DID_TIME_OUT

NVMe:

I/O timeout
reset controller
Device not ready
controller is down
CSTS=0xffffffff

USB:

reset SuperSpeed USB device
device descriptor read error
USB disconnect

Единичный сброс не всегда означает повреждение носителя. Повторение под нагрузкой, потеря устройства или появление I/O-ошибок требует немедленной реакции.

Как различать тип проблемы

Состояние точек монтирования

Проверить фактические параметры:

findmnt -rn -o TARGET,SOURCE,FSTYPE,OPTIONS

Найти файловые системы в режиме ro:

findmnt -rn -o TARGET,SOURCE,FSTYPE,OPTIONS | grep -E '(^|,)ro(,|$)'

Проверить конкретную точку:

findmnt --target <путь>

Реагировать

Нужно реагировать, если рабочая файловая система, ранее доступная на запись, неожиданно стала ro.

Типовые последствия:

Read-only file system
EROFS

Одновременно проверить журнал:

journalctl -k -b --no-pager | grep -Ei \
'read-only|remount|EXT4-fs error|JBD2|XFS|BTRFS|I/O error'

Можно пропустить

Режим ro является штатным для:

• squashfs;
• iso9660;
• установочных образов;
• некоторых snapshot;
• файловых систем, специально указанных в /etc/fstab с параметром ro.

Заполненность и inode

Проверить объём:

df -hT

Проверить inode:

df -ih

Критические состояния

Use%  = 100%
IUse% = 100%

Наиболее опасно заполнение:

• /;
• /var;
• /tmp;
• /home;
• каталогов баз данных;
• каталогов журналов;
• файловых систем приложений.

Требует реакции заранее

Use%  > 90%
IUse% > 90%

Это не означает повреждение файловой системы, но создаёт риск отказа служб, невозможности записи журналов и остановки приложений.

Проверить место без перехода на другие файловые системы:

sudo du -xhd1 <точка_монтирования> | sort -h

Если df показывает занятое место, которого не видно через du, проверить удалённые, но открытые файлы:

sudo lsof +L1

lsof может отсутствовать в минимальной установке.

Диагностика ext4

Показать сообщения ext4 и журнала JBD2:

journalctl -k -b --no-pager | grep -Ei 'EXT4-fs|JBD2'

Реагировать немедленно

EXT4-fs error
Aborting journal
Journal has aborted
Remounting filesystem read-only
I/O error while writing superblock
unable to read superblock

Переход ext4 в read-only может быть штатной защитной реакцией на обнаруженную ошибку, если задан режим errors=remount-ro.

Требует проверки

warning: mounting fs with errors
orphan cleanup

orphan cleanup сам по себе возможен после нештатного выключения. Опасность подтверждается, если далее появляются ошибки, остановка журнала или переход в read-only.

Обычно штатно

recovery complete
mounted filesystem

Штатное восстановление журнала без последующих ошибок не является доказательством повреждения.

Диагностика XFS

Показать сообщения XFS:

journalctl -k -b --no-pager | grep -i 'XFS'

Показать геометрию без изменения:

xfs_info <точка_монтирования>

Реагировать немедленно

XFS ... Corruption detected
XFS ... Metadata corruption detected
XFS ... metadata I/O error
XFS ... Log I/O Error
XFS ... Filesystem has been shut down
XFS ... Please unmount the filesystem and rectify the problem

При shutdown XFS прекращает обычные операции, чтобы не продолжать изменение повреждённых метаданных.

Обычно штатно

Mounting V5 Filesystem
Ending clean mount
Starting recovery
Ending recovery

Восстановление журнала после некорректного завершения работы допустимо, если далее нет corruption, I/O error или shutdown.

Диагностика Btrfs

Показать сообщения:

journalctl -k -b --no-pager | grep -i 'BTRFS'

Проверить счётчики ошибок устройств:

sudo btrfs device stats <точка_монтирования>

Проверить состояние ранее запущенного scrub:

sudo btrfs scrub status <точка_монтирования>

Счётчики btrfs device stats

write_io_errs
read_io_errs
flush_io_errs
corruption_errs
generation_errs

Ненулевые значения требуют проверки. Рост счётчиков означает продолжающуюся проблему.

Реагировать немедленно

BTRFS error
parent transid verify failed
checksum verify failed
csum failed
unable to read tree root
forced readonly
uncorrectable_errors > 0

uncorrectable_errors после scrub означает, что Btrfs не смог восстановить данные из доступной избыточной копии.

Требует проверки

corrected_errors > 0

Ошибка была исправлена из другой копии, но причина повреждения остаётся: носитель, кабель, путь, память или прежний сбой записи.

Диагностика FAT и NTFS

Показать сообщения:

journalctl -k -b --no-pager | grep -Ei 'FAT-fs|VFAT|NTFS|ntfs3'

Реагировать

FAT-fs error
Directory bread(block ...) failed
unable to read boot sector
ntfs3 ... error
failed to load $MFT
I/O error

Требует проверки

Volume was not properly unmounted
filesystem is dirty
Windows is hibernated

Такие сообщения не всегда означают физическое повреждение. Они могут быть результатом:

• аварийного отключения;
• Windows Fast Startup;
• гибернации Windows;
• извлечения накопителя без безопасного отключения.

Не принуждать подключение на запись до определения причины.

SMART для SATA SAS и USB-накопителей

Проверить наличие smartctl:

command -v smartctl

Показать полный отчёт:

sudo smartctl -x /dev/<диск>

Пример:

sudo smartctl -x /dev/sda

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

sudo smartctl --scan-open

Реагировать немедленно

SMART overall-health self-assessment test result: FAILED
SMART Health Status: BAD

Для ATA-дисков опасны ненулевые или растущие значения:

Current_Pending_Sector
Offline_Uncorrectable
Reported_Uncorrect
Command_Timeout
Reallocated_Sector_Ct
Reallocated_Event_Count
Spin_Retry_Count

Особенно критичны:

• ожидающие переназначения сектора;
• неисправимые сектора;
• ошибки чтения важных данных;
• рост значений между проверками.

Требует проверки пути, а не поверхности

UDMA_CRC_Error_Count
Interface_CRC_Error_Count

Рост этих счётчиков чаще указывает на:

• кабель;
• разъём;
• порт;
• питание;
• контроллер;
• транспортный путь.

Само накопленное историческое значение не обязано уменьшаться после устранения причины. Важен дальнейший рост.

Не считать универсальным признаком отказа

Нельзя одинаково трактовать все vendor-specific атрибуты SSD. Названия, нормализованные значения и RAW-поля могут различаться по производителям и моделям.

Обычно информационны:

Power_On_Hours
Power_Cycle_Count
Start_Stop_Count
Unsafe_Shutdown_Count

Они используются как контекст, а не как самостоятельный диагноз.

Температура

Проверить текущую температуру и пределы в отчёте SMART.

Не применять единый порог ко всем моделям. Реагировать следует на:

• превышение предела, указанного устройством;
• SMART temperature warning;
• повторяющийся перегрев;
• связь перегрева с ошибками или сбросами устройства.

Диагностика NVMe

Проверить через smartctl:

sudo smartctl -x /dev/nvme0

Если установлен nvme-cli:

sudo nvme smart-log /dev/nvme0

Реагировать немедленно

critical_warning != 0
media_errors > 0
available_spare ниже порога
устройство перешло в read-only

Также критичны повторяющиеся сообщения ядра:

I/O timeout
reset controller
controller is down
Device not ready

Требует наблюдения

unsafe_shutdowns
error_log_entries
percentage_used

Особенности:

• unsafe_shutdowns показывает историю аварийных отключений;
• error_log_entries может включать не только повреждение носителя;
• percentage_used является оценкой износа, а не процентом свободного места;
• достижение percentage_used = 100 означает исчерпание расчётного ресурса, но не гарантирует немедленную остановку устройства.

Основным аварийным признаком NVMe остаётся critical_warning вместе с media/data integrity errors и сообщениями ядра.

Linux Software RAID

Показать состояние:

cat /proc/mdstat

Подробности массива:

sudo mdadm --detail /dev/md0

Штатное состояние

Для массива из двух устройств:

[UU]

Каждая буква U означает активное устройство.

Деградация

[U_]
[_U]

Символ _ означает отсутствующее или неисправное устройство.

Идущая операция

resync
recovery
reshape
check

Эти состояния не обязательно являются ошибкой, но должны контролироваться до завершения.

Реагировать немедленно

• массив отмечен как degraded;
• число активных устройств меньше требуемого;
• операция recovery останавливается;
• появляются I/O-ошибки участника;
• RAID5/RAID6 одновременно находится в состояниях dirty и degraded.

Multipath

Проверить службу:

systemctl is-active multipathd

Показать пути:

sudo multipath -ll

Нормальные обозначения

В зависимости от версии и устройства встречаются:

active
ready
running

Неисправный путь

failed
faulty
offline
shaky
ghost

ghost может быть штатным состоянием резервного пути на active/passive СХД. Оценивать его нужно по политике конкретной СХД.

Требует реакции

Один путь failed или faulty при наличии исправных путей:

• данные обычно продолжают передаваться;
• отказоустойчивость уже снижена;
• требуется проверка HBA, кабеля, SAN-коммутатора, контроллера и порта СХД.

Критично

• все пути к LUN находятся в failed, faulty или offline;
• карта Multipath отсутствует, хотя отдельные SCSI-пути видны;
• процессы зависают в I/O;
• журнал содержит no usable paths, all paths down или повторяющиеся SCSI timeout.

При включённом queue_if_no_path операции могут не завершаться ошибкой, а зависать до восстановления пути.

LVM Thin Pool

Проверить наличие thin pool и его заполнение:

sudo lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent

Реагировать

Особое внимание:

Data% = 100
Meta% = 100

Заполнение metadata thin pool критично и может остановить операции записи.

Значения выше 90% требуют планового расширения или освобождения пространства.

Что можно пропустить

Обычно не требуют аварийных действий без дополнительных симптомов:

Когда прекратить работу с носителем

Прекратить обычную эксплуатацию и не запускать тяжёлые проверки, если обнаружено хотя бы одно состояние:

• повторяющиеся ошибки чтения;
• Current_Pending_Sector > 0;
• Offline_Uncorrectable > 0;
• SMART FAILED;
• NVMe critical_warning;
• исчезновение устройства во время работы;
• постоянные controller reset или link reset;
• XFS shutdown;
• ext4 abort journal;
• Btrfs uncorrectable_errors;
• ФС перешла в read-only вместе с I/O-ошибками;
• ошибки быстро растут при повторной проверке.

Не запускать до сохранения важных данных:

длительный SMART self-test
btrfs scrub
badblocks
fsck с исправлением
xfs_repair
btrfs check --repair
RAID rebuild на подозрительном комплекте дисков

Что зафиксировать перед передачей проблемы

Сохранить общую схему:

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Сохранить журнал ядра:

journalctl -k -b --no-pager > /root/kernel-storage-current.txt

Предыдущая загрузка:

journalctl -k -b -1 --no-pager > /root/kernel-storage-previous.txt

SMART:

sudo smartctl -x /dev/<диск> > /root/smart-<диск>.txt

RAID:

cat /proc/mdstat > /root/mdstat.txt

Multipath:

sudo multipath -ll > /root/multipath.txt

Зафиксировать вручную:

Устройство:
Модель и серийный номер:
Файловая система:
Точка монтирования:
Режим rw/ro:
Когда появились ошибки:
Повторяются ли ошибки:
Есть ли важные данные:
Есть ли резервная копия:

Источники

• Документация ALT Linux 10.4: журнал systemd
• Документация ядра Linux: ext4
• Документация ядра Linux: XFS
• Документация Btrfs: device stats
• Документация Btrfs: scrub
• Проект smartmontools
• NVM Express: SMART и журнал ошибок
• Документация ядра Linux: MD RAID