Запись на диск вдруг отказывает, приложения сыплют ошибками, а в dmesg - строки об ошибках ввода-вывода и о переводе файловой системы в режим только для чтения. Это типичное поведение ext4 при встрече с проблемами носителя: ядро защищает данные от разрушения и запрещает запись до разбирательства. В этой статье полный маршрут диагностики: почему файловые системы сами уходят в read-only, как по журналу найти момент и причину, как через smartctl отличить умирающий диск от проблем кабеля или контроллера, и что делать после диагноза - от восстановления до плановой замены.
Почему файловая система сама уходит в read-only
Ext4 и большинство современных файловых систем проектировались с приоритетом целостности данных. Когда ядро встречает ошибку записи - таймаут устройства, ошибку сектора, отказ команды - оно прекращает запись и переводит файловую систему в режим только для чтения, потому что продолжение работы с несогласованными данными гарантированно портит содержимое. Со стороны это выглядит внезапно: сервисы продолжают работать на чтение, но любая попытка записи возвращает ошибку.
Первичная реакция понятна и не требует паники: перевод в read-only - защитная мера, а не поломка поверх неё. Задача инженера - установить, что именно за ошибки породили защиту, и это устанавливается чтением журнала, о котором следующий раздел.
Первичная диагностика по journalctl
Момент перехода в read-only фиксируется в журнале ядра, и найти его - первый шаг. journalctl -k | grep -i -E "read-only|error|I/O" за последние часы показывает строки вида EXT4-fs error (device sda1) и Remounting filesystem read-only. Время этих строк - момент инцидента, и вокруг него лежат первичные улики: за минуту до перевода почти всегда есть сообщения о конкретных операциях, которые не удались.
Дальше список сужается по типам. Oшибка вида "media error" или "unrecoverable read error" указывает на проблемные сектора самого носителя. Ошибки вида "task aborted" или "timeout" говорят о задержке ответов устройства - это может быть как диск, так и кабель, контроллер или перегруженная шина. Кластер ошибок за короткое время указывает на конкретный момент стресса, а одиночные растянутые ошибки - на постепенную деградацию.
Для файловых систем на LVM и mdadm адресация ошибок чуть сложнее: журнал говорит о логическом устройстве, и следующий шаг - спуститься вниз по стеку, от dm-устройства к физическим носителям, через dmsetup ls и содержимое /proc/mdstat. На каждом уровне проверяется собственный журнал ошибок.
Анализ ошибок ввода-вывода через smartctl
SMART - следующий обязательный шаг, и самый информативный. smartctl -a /dev/sda выдаёт атрибуты носителя, из которых читается состояние прямо. Reallocated_Sector_Ct - количество переназначенных секторов: рост за последние недели означает деградацию поверхности. Current_Pending_Sector - сектора, ожидающие переназначения: ненулевое значение - прямой признак проблем чтения. UDMA_CRC_Error_Count - ошибки передачи по кабелю: рост этого счётчика говорит, что дело не в диске, а в шлейфе или разъёме.
Практический порядок чтения: сперва общее здоровье (строка overall-health self-assessment), затем счётчики ошибок, затем тесты. Короткий тест smartctl -t short занимает минуты и проверяет базовую механику; расширенный -t long читает поверхность целиком и занимает часы, но даёт окончательный ответ о пригодности носителя.
Динамика важнее абсолютных значений: диск с тремя переназначенными секторами за три года службы - норма; диск, добавивший десять за неделю, - кандидат на замену, даже если тесты формально проходят. Опытные инженеры ведут историю SMART по парку, и решение о замене принимается по тренду.
Отличие диска от кабеля от контроллера
Три источника ошибок ввода-вывода дают похожие симптомы, и для различения существует короткая методика. Кабель и соединения проявляются через ошибки передачи - растущий счётчик UDMA_CRC_Error_Count при здоровых внутренних атрибутах диска. Диск проявляется через носители - reallocated и pending секторы при чистом кабеле. Контроллер и шина подозреваются, когда несколько дисков на одном канале сыплют ошибками одновременно, и это уже уровень выше - драйвер, прошивка HBA или перегрев чипсета.
Практический тест различения: перестановка. Переставить диск на другой кабель и порт - и посмотреть, ушли ли ошибки CRC. Если диск физически доступен, подключить его к другому серверу напрямую. Для дисков в массиве проверка проще: mdadm и LVM продолжают работу при выпадении одного носителя, и подозреваемый выводится из массива для диагностики без остановки сервиса.
Восстановление и когда оно уместно
После диагноза путь зависит от источника. Если причина - единичные сбойные секторы, файловая система чинится на отмонтированном или read-only разделе: fsck.ext4 -f /dev/sda1, и утилита перестроит структуры вокруг проблемных участков. Для XFS - xfs_repair, для Btrfs - собственный btrfs check с осторожностью из-за чувствительности к состоянию массива.
Если причина - умирающий диск, сначала данные, потом всё остальное: rsync важных каталогов на запасной носитель, и только затем любые repairs на пострадавшем. Попытка починить файловую систему на деградирующем носителе усугубляет состояние - классическая ошибка спешки, которую совершают почти все по одному разу.
Замена диска в LVM и mdadm
Когда решение о замене принято, процедура зависит от слоя. В mdadm: отметить сбойный диск fault через mdadm --fail, вывести из массива --remove, заменить физически, добавить новый --add, дождаться ресинка через cat /proc/mdstat. В LVM поверх software RAID порядок тот же с ожиданием восстановления массива. В LVM без RAID диск сначала выводится из группы томов через pvmove - перенос данных на живые носители - и затем vgreduce, после чего замена выполняется свободно.
Ключевая дисциплина при замене: убедиться, что удаляется именно отказавший диск - по серийному номеру из smartctl и по светодиоду локатора через sysfs, если поддерживается. В многодисковых серверах перепутать носители проще, чем кажется, а цена ошибки высока.
Профилактика и мониторинг
Всё описанное предотвращается или рано ловится мониторингом. smartmontools с daemon-режимом следят за атрибутами и присылают алерты при росте проблемных счётчиков - это ловит деградацию за недели до отказа. Мониторинг ошибок в журнале ядра через экспортёр типа node_exporter с колlapse на ошибки I/O даёт раннее предупреждение по всему парку. Резервирование уровнем выше - RAID или LVM с зеркалированием - превращает отказ отдельного диска из аварии в плановую замену.
История из практики
Типичный случай: файловый сервер в пятницу вечером перевёл корень в read-only, приложения посыпались ошибками. Журнал показал пачку media errors на sda за минуты до перевода, SMART - 40 растущих pending-секторов. Диск был клонирован через ddrescue на горячую замену, файловая система на копии прошла fsck без потерь, сервер перезагрузился со свежим диском к утру субботы. Секрет аккуратного финала в порядке действий: сначала образ умирающего носителя, потом любые repairs, и никакой спешки в обратном порядке.
Памятка
Порядок всей темы: журнал переводов в read-only, тип ошибок, SMART и динамика счётчиков, различение источника, сначала образ - потом починка, замена по процедуре слоя, мониторинг на будущее. От алерта до замены диска проходит вечер, и при правильном порядке действий данные не теряются вовсе - что и есть главный критерий успешной диагностики ошибок ввода-вывода.
Порядок действий при живой системе
Если read-only застал систему работающей, порядок отличается от холодного разбора. Сначала фиксируются улики: journalctl -k за последние часы копируется наружу, smartctl -a снимается в файл, потому что после перезагрузки часть контекста исчезнет. Затем оценивается слой: корень пострадал или данные? Если только данные - сервисы переводятся на доступные каталоги, а проблемный раздел отмонтируется для диагностики.
Если пострадал корень - сервер продолжит работать на чтение, и это окно используется для образа: rsync критичных данных на запасной носитель пока система ещё цела. Перезагрузка выполняется только после снятия образа, потому что загрузиться обратно с повреждённой файловой системой может и не получиться.
Образ через ddrescue как страховка
Деградирующий диск требует особого обращения: каждая операция чтения может стать последней. ddrescue читает носитель, пропуская сбойные области и возвращаясь к ним потом, и потому снимает максимум данных при минимуме стресса для механики: ddrescue /dev/sda /backup/sda.img /backup/sda.mapfile. Карта в отдельном файле отслеживает, что прочитано, и позволяет продолжить с того же места после перерыва.
После снятия образа вся работа идёт с ним: fsck и восстановление данных выполняются на копии через loop-устройство, а оригинальный носитель отправляется на замену или в лабораторию при особых случаях. Такой порядок - разница между "спасли максимум" и "долечили до смерти": классическая рекомендация всех руководств по восстановлению, которую стоит принять как аксиому.
Что проверять после замены
Завершение истории - не момент установки нового диска, а подтверждение восстановления. После ресинка массива: cat /proc/mdstat до состояния active и полного восстановления. После fsck: монтирование и проверка целевых каталогов. Затем - контрольный журнал: journalctl -k за новый период без ошибок I/O, и SMART нового носителя с нулевыми проблемными счётчиками. Пять минут проверки закрывают цикл и переводят инцидент из разряда "вроде починили" в разряд "подтверждено работает".
Реакция разных файловых систем на ошибки
Для полноты картины полезно понимать, что реакция на ошибки ввода-вывода - свойство конкретной файловой системы. Ext4 переводит себя в read-only при встрече с ошибками метаданных, и это самый частый источник сценариев этой статьи. XFS вместо перевода в read-only останавливает себя с выраженным сообщением и ожидает xfs_repair. Btrfs помечает устройство с ошибками и отказывается писать на него, продолжая работу на остальных при наличии зеркалирования. Знание этих различий объясняет разный внешний вид одной и той же корневой проблемы и подсказывает правильную утилиту для восстановления каждой конкретной ФС.
И общее для всех правило остаётся неизменным: ошибка ввода-вывода - всегда симптом нижнего слоя, и чинить следует причину, а не только следствие на уровне файловой системы. Fsck без снятия образа с деградирующего диска - это ремонт крыши над горящим домом.
Замыкающий принцип темы
Перевод в read-only - не поломка системы, а честный сигнал о том, что нижний слой требует внимания. Инженер, который читает этот сигнал по журналу, отличает носитель от кабеля по SMART и соблюдает порядок "образ - потом ремонт", проходит эту аварию за вечер с сохранёнными данными. Инженер, который торопится, рискует обменять восстановимую ситуацию на безнадёжную, и именно здесь проходит граница между профессией и её противоположностью.
Одно предложение на память
Всё многообразие темы держится на короткой формуле: сначала образ, потом ремонт, замена по тренду SMART, мониторинг на будущее - и даже самые шумные ошибки ввода-вывода остаются просто инцидентом из разряда плановых, а не катастрофой из разряда ночных.
И последняя строчка, которую стоит держать в голове: место на диске и здоровье носителя связаны сильнее, чем кажется, - почти полные и сильно фрагментированные разделы ускоряют деградацию механических дисков, и освобождение места после этой аварии будет полезно вдвойне - и системе, и железу, которое следующий год проработает спокойнее.
Пусть ваши диски сообщают о недугах рано и вежливо, а диагностика остаётся рутиной с чек-листом.
Конец.Сделано.