Linux: EIO и Buffer I/O error on dev — диагностика диска, ФС и контроллера

Сообщения вида Buffer I/O error on dev sda, blk_update_request: I/O error и возвращаемый приложениями EIO — это симптом того, что ядро Linux не смогло надёжно прочитать или записать данные на блочное устройство. Иногда причина банальна (временный сбой стореджа в виртуализации или деградация RAID), но чаще это начало проблем накопителя, контроллера, питания или транспорта (кабель, бэкплейн).

Ниже — пошаговый план: как быстро оценить масштаб, собрать доказательства (логи/SMART), отличить «умирает диск» от «побилась ФС» и что делать, чтобы не усугубить ситуацию и успеть спасти данные.

Что означают EIO, I/O error и Buffer I/O error on dev

EIO — код ошибки Input/output error, который получает приложение, когда системный вызов чтения/записи провалился на уровне ядра и драйверов хранения.

Buffer I/O error on dev X — сообщение от подсистемы буферного ввода-вывода: операция с буфером страницы (часто чтение метаданных/данных ФС) не была выполнена.

blk_update_request: I/O error — низкоуровневое сообщение блочного слоя: запрос на чтение/запись к устройству завершился ошибкой. Часто рядом видны сектор/LBA и тип операции (READ/WRITE/FLUSH/DISCARD).

Если в dmesg есть blk_update_request и массовые Buffer I/O error, сначала думайте о проблемах устройства/транспорта, а уже потом — о «порче файловой системы».

Типичные причины: от «железа» до виртуализации

Причины повторяются, но лечатся по-разному — поэтому важно быстро классифицировать проблему по признакам.

1) Деградация диска (HDD/SSD/NVMe)

Переаллокации, ошибки чтения, растущие pending-сектора, сбои контроллера SSD или исчерпание ресурса могут давать ровно такой набор симптомов. Для NVMe часто видны таймауты/reset в логах и сигналы в SMART-логах NVMe.

2) Проблемы канала/контроллера

SATA/SAS-кабель, бэкплейн, HBA/RAID-контроллер, нестабильное питание — всё это вызывает повторяющиеся ошибки чтения/записи, иногда «скачущие» по разным LBA. В виртуальной машине аналог — проблемы на сторедж-бэкенде, высокая задержка, таймауты, события миграций.

3) RAID деградировал или «сыпется» массив

При деградации RAID вы увидите события mdadm, пересборку, ошибки на одном из членов. Ошибки могут проявляться как на логическом устройстве (/dev/mdX), так и на нижележащем (/dev/sdX).

4) Ошибки файловой системы

Иногда первопричина — именно ФС (битые метаданные). Но даже тогда корень нередко в прошлых проблемах хранения. Отличительный признак: устройство читается стабильно (нет таймаутов/ошибок на уровне диска), а в логе доминируют сообщения ext4/XFS о несогласованности.

5) Особые случаи: FLUSH/DISCARD, зависания и remount ro

Если ошибки идут на FLUSH/FUA — возможна проблема с кешем/контроллером или последствия внезапных отключений питания. Если после ошибок раздел перемонтируется в read-only — это защитная реакция ФС (часто ext4) на невозможность безопасно писать.

Первые действия: как не усугубить и быстро оценить ущерб

В первые минуты цель простая: остановить дальнейшую порчу данных, понять «что именно падает» и собрать максимум сигналов.

Шаг 0. Если это прод — зафиксируйте состояние и снизьте записи

• Если есть реплика/резервная копия — готовьтесь переключаться.
• Если бэкапа нет или он сомнительный — минимизируйте записи: остановите тяжёлые сервисы (БД, очереди, индексы), фоновые задания, агрессивные ротации логов.
• Не запускайте проверки, которые пишут на диск (включая «лечебные» тесты), пока не поймёте картину.

Шаг 1. Посмотрите свежие ошибки storage в dmesg/journal

Нас интересуют таймауты, ресеты, ошибки READ/WRITE, номера секторов, и какое именно устройство ругается: sda, nvme0n1, dm-0, md0.

dmesg -T | tail -n 200
journalctl -k -b --no-pager | tail -n 300

Ключевые фразы для первичной диагностики:

• Buffer I/O error on dev
• blk_update_request: I/O error
• rejecting I/O to offline device
• timed out, reset, link is slow to respond
• EXT4-fs error, сообщения XFS, перемонтирование в read-only

Шаг 2. Привяжите «dev» к реальному диску и точке монтирования

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /

Если в логах фигурирует dm-0 или md0, разверните цепочку (LVM/шифрование/RAID):

lsblk -o NAME,TYPE,PKNAME,HCTL,SIZE,MOUNTPOINTS
ls -l /dev/disk/by-id/

Шаг 3. Проверьте, не деградировал ли RAID (mdadm)

cat /proc/mdstat
mdadm --detail /dev/md0

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

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

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

SMART и NVMe: что смотреть и как интерпретировать

SMART — самый быстрый индикатор аппаратных проблем. Для SATA/SAS обычно используют smartctl, для NVMe подходят и smartctl, и утилита nvme.

SMART для SATA/SAS (smartctl)

smartctl -a /dev/sda
smartctl -x /dev/sda

Чаще всего коррелируют с I/O ошибками такие атрибуты:

• Reallocated_Sector_Ct — уже заменённые сектора (рост — плохой знак).
• Current_Pending_Sector — сектора «под вопросом» (часто совпадают с местами, где ловите EIO).
• Offline_Uncorrectable — необрабатываемые ошибки чтения.
• UDMA_CRC_Error_Count — часто указывает на кабель/контакт/порт/контроллер, а не на поверхность диска.

Короткий self-test (если нужно подтверждение и диск ещё «держится»):

smartctl -t short /dev/sda
smartctl -l selftest /dev/sda

Длинный тест на нестабильном диске может ускорить деградацию. Если данные критичны и бэкапа нет — сначала снимайте копию, тесты оставьте на потом.

NVMe: nvme smart-log и типовые сигналы

nvme list
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0

Что настораживает:

• Рост media_errors и num_err_log_entries.
• Ненулевой/высокий critical_warning.
• В журнале ядра — повторяющиеся timeout/reset для NVMe.

Как отличить «умирает диск» от «побилась файловая система»

Эта развилка определяет порядок действий: копирование vs ремонт.

Признаки аппаратной проблемы (диск/контроллер/транспорт)

• В dmesg есть timeouts, reset, ошибки чтения на разных LBA.
• SMART/NVMe показывает pending/media errors/uncorrectable.
• Ошибки возникают даже на «сырых» чтениях блочного устройства, а не только при доступе к одной директории.

Признаки проблем ФС при стабильном устройстве

• SMART «чистый», таймаутов/ресетов нет.
• В логах много сообщений ext4/XFS о несогласованности метаданных.
• Проблема воспроизводится в конкретной области дерева (часто в одном каталоге/томе/инодах).

После успешного fsck или xfs_repair всё равно перепроверьте storage-логи и SMART: если первопричина аппаратная, ошибка вернётся.

Если у вас регулярно всплывают вопросы про параметры монтирования и «мелкие» оптимизации, посмотрите материал про параметры atime/relatime и влияние на количество записей — он помогает снизить лишнюю нагрузку на диск в повседневной эксплуатации.

Безопасный порядок действий для спасения данных

Если данные важны, действуйте как при восстановлении: сначала «зафиксировать» и скопировать, потом ремонтировать.

1) Снизьте записи и снимите бэкап/снапшот, если возможно

Остановите сервисы, которые активно пишут. Если платформа позволяет сделать снапшот на уровне гипервизора/хранилища — это часто лучший «быстрый якорь» перед дальнейшими действиями.

2) Проверьте, не перемонтировалась ли ФС в read-only

findmnt -no TARGET,OPTIONS /

Read-only может спасти метаданные от дальнейшей порчи, но приложения начнут падать — это ожидаемо.

3) Сначала копирование, потом диагностика «на запись»

Проверки уровня badblocks в режимах с записью, ресинк RAID и «жёсткие» тесты повышают нагрузку. Если диск нестабилен, сначала получите копию на другой носитель.

Для поблочного копирования в аварийных случаях часто используют ddrescue (если доступно в вашей среде). Общая идея: копировать с пропусками плохих областей, а затем дочитывать их повторными проходами. Важный момент — писать результат нужно на другой физический диск или в отдельный образ, а не на источник.

4) После копии — проверка и ремонт ФС на копии или на новом диске

В идеале: разворачиваете копию/клон на исправном диске и уже там запускаете инструменты восстановления (лучше из rescue-окружения, чтобы раздел был размонтирован).

• ext4: fsck.ext4
• XFS: xfs_repair

badblocks: когда уместен и как не навредить

badblocks полезен для подтверждения проблем, но легко превращается в «добиватель» умирающего диска.

• Режимы -n и особенно -w пишут на устройство: на деградирующем диске это может ускорить смерть и усилить порчу данных.
• Режим чтения безопаснее, но всё равно создаёт длительную нагрузку последовательным чтением.

Если задача именно «проверить диск», а данные уже спасены, выполняйте тесты на отмонтированном разделе и закладывайте время: это долгие операции.

Что делать при деградации RAID (mdadm)

При деградации массива важны две вещи: не потерять оставшиеся диски и не запустить разрушительную нагрузку на проблемном железе.

Проверка состояния

cat /proc/mdstat
mdadm --detail /dev/md0

Практичные рекомендации

• RAID1: перед заменой диска убедитесь, что второй «здоров» по SMART, и только потом давайте массиву восстановиться.
• RAID5/6: при множественных I/O ошибках риски резко растут; иногда разумнее сначала снять поблочные копии с дисков (или хотя бы с подозрительного), а уже потом пытаться собирать массив.
• Если видите CRC/link ошибки — сначала проверьте транспорт и контроллер, иначе новый диск тоже начнёт «сыпаться» в логах.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Как читать «страшные» строки в dmesg и что из них извлечь

В большинстве сообщений есть три ключа: устройство, операция и адрес (sector/LBA). Примерная логика разбора:

• Ошибки на одном и том же секторе часто указывают на локально повреждённую область.
• Ошибки «вразнобой» плюс timeouts/reset — чаще канал/контроллер или деградация накопителя целиком.
• Ошибки на dm-* требуют посмотреть, что под ними: LVM, шифрование, RAID, multipath.

Чтобы быстро собрать «выжимку», удобно отфильтровать журнал ядра:

journalctl -k -b --no-pager | grep -E 'blk_update_request|Buffer I/O error|I/O error|EXT4-fs error|XFS|nvme|ata[0-9]'

Ошибки файловой системы: что делать для ext4 и XFS

ext4

При серьёзных ошибках ext4 может перемонтировать раздел в read-only. Типовой путь: загрузка в rescue, размонтировать раздел, затем проверка:

fsck.ext4 -f /dev/sda2

Если том большой и простой критичен — иногда быстрее подняться из реплики/бэкапа, чем чинить «на месте».

XFS

XFS обычно чинят xfs_repair на размонтированной ФС:

xfs_repair /dev/sda2

Для сравнения подходов ext4 и XFS, а также нюансов эксплуатации на сервере, может пригодиться статья выбор и настройка ext4/XFS на VDS.

Как проверить контроллер, кабели и питание

Если SMART «чистый», но растёт UDMA_CRC_Error_Count, или в dmesg много reset/link error — высока вероятность проблем транспорта.

• Физический сервер: заменить SATA/SAS-кабель, переставить диск в другой порт, проверить бэкплейн и питание.
• RAID/HBA: проверить логи контроллера и состояние батареи/кеша (если применимо).
• Виртуальная машина: проверить статус хранилища и события платформы (задержки, ошибки I/O, миграции).

На Linux полезно сопоставить ошибки с SCSI-адресом (HCTL):

lsblk -o NAME,HCTL,MODEL,SERIAL,SIZE
journalctl -k -b --no-pager | grep -E 'scsi|reset|timed out|I/O error'

После инцидента: профилактика и мониторинг

Когда система стабилизирована, сделайте выводы и превратите их в мониторинг:

• Регулярные SMART-проверки и алерты по ключевым атрибутам.
• Алерты по строкам ядра: blk_update_request, Buffer I/O error, reset/timeouts.
• Проверка RAID-статуса (/proc/mdstat) и уведомления.
• Регулярные тесты восстановления из бэкапов.

Если вы размещаете проекты на VDS или виртуальном хостинге, добавьте в регламент простую проверку «диск/RAID/логи ядра» хотя бы раз в неделю: это часто ловит деградацию до падения сервиса.

Короткий чек-лист (когда нужно действовать быстро)

1. Остановить лишние записи и зафиксировать логи: journalctl -k, dmesg.
2. Понять, какое устройство падает: lsblk, findmnt, цепочка dm/md.
3. Проверить RAID: cat /proc/mdstat, mdadm --detail.
4. Снять признаки здоровья: smartctl или nvme smart-log.
5. Если данные важны — сначала копия/снапшот/восстановление на новый носитель, потом fsck/xfs_repair и стресс-тесты.

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

Если ошибка повторяется, SMART/NVMe показывает деградацию, либо storage нестабилен на уровне платформы, «ремонт на месте» превращается в лотерею. Практичнее поднять новую систему, восстановить данные из бэкапа/реплики и уже потом разбираться с первопричиной без давления времени.

Критерий простой: важнее восстановить сервис и сохранить данные, чем доказать, какой именно сектор «плохой».