Linux: Read-only file system (ro) — почему ext4/XFS внезапно становятся только для чтения и как восстановить

Когда Linux внезапно переводит файловую систему в режим ro (read-only), это почти всегда защитная реакция: ядро видит ошибки ввода-вывода или неконсистентность метаданных и предпочитает «заморозить» запись, чтобы не усугубить повреждение. Для администратора это выглядит как лавина ошибок: «Read-only file system», «cannot create», падение сервисов и невозможность корректно перезапустить приложения.

Ниже — практичный алгоритм диагностики и восстановления: как быстро подтвердить факт remount ro, где искать первопричину (ошибки ext4/XFS или I/O), как действовать через emergency/rescue и чем отличается ремонт ext4 (fsck) от XFS (xfs_repair). Параллельно разберём проверку диска через smartctl и nvme smart-log.

Что значит Read-only file system и почему ядро делает remount ro

Сообщение «read-only file system» чаще всего означает не то, что раздел смонтировали «специально», а то, что ядро автоматически перемонтировало файловую систему в ro после критических ошибок. Типовые причины:

• Ошибки устройства хранения: таймауты, сбои чтения/записи, проблемы с контроллером, деградация SSD/HDD. В логах часто видно I/O error, blk_update_request: I/O error, Buffer I/O error.

• Ошибки файловой системы: на ext4 — «EXT4-fs error», «journal has aborted»; на XFS — «metadata corruption detected», «xfs_do_force_shutdown».

• Цепочка событий из-за переполнения диска: само ENOSPC обычно не делает ro, но переполненные разделы часто приводят к аварийным остановкам сервисов, зависаниям и «грязным» перезагрузкам, после которых всплывают ошибки ФС.

• Грязное выключение (poweroff/reset): повышает риск, особенно если носитель уже «на грани».

Перемонтирование в ro — симптом. Если просто вернуть rw и продолжить запись, можно быстро превратить частичное повреждение в тяжёлое (и усложнить восстановление данных).

Быстрая диагностика: где и что смотреть (dmesg, journalctl)

Задача первых минут — подтвердить режим ro и найти первичное сообщение, которое его вызвало. Оно почти всегда есть в логах ядра незадолго до строки про remount.

1) Проверяем, что смонтировано как ro

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /
mount | grep -E ' on / | on /var | on /home '

Ищите в опциях ro. Если корень / в ro — это почти всегда аварийная ситуация (обновления, логирование, базы и т. п. начнут «сыпаться»).

2) Ищем причины в сообщениях ядра: dmesg

dmesg -T | tail -n 200

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

dmesg -T | egrep -i 'read-only file system|remount|EXT4-fs error|journal has aborted|XFS .*corrupt|xfs_do_force_shutdown|I/O error|Buffer I/O|blk_update_request|nvme|ata|reset'

Если вы видите Remounting filesystem read-only, рядом обычно есть и «первопричина»: конкретная ошибка ext4/XFS или ошибки блока/диска.

3) Логи systemd/journald: journalctl

journalctl -k -b --no-pager | tail -n 200
journalctl -b --no-pager | egrep -i 'read-only file system|remount ro|EXT4-fs|XFS|I/O error|fsck|xfs_repair|emergency'

Если инцидент был на предыдущей загрузке:

journalctl -k -b -1 --no-pager | tail -n 200

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

Типовые сообщения и как их интерпретировать

EXT4: ext4 errors, journal aborted

Частые строки в ядре:

• EXT4-fs error (device ...): ... — ошибка метаданных/структур.

• Aborting journal on device ... или journal has aborted — журналирование остановлено, запись небезопасна.

• Remounting filesystem read-only — ядро переводит FS в ro.

Для ext4 стандартный путь — проверка и исправление через fsck на размонтированном разделе.

XFS: forced shutdown и уход в ro

Характерные признаки:

• XFS (...): metadata corruption detected — повреждение метаданных.

• xfs_do_force_shutdown — XFS делает «аварийное отключение» и часто уходит в ro.

Для XFS нужен xfs_repair на размонтированном томе. «Обычный» fsck для XFS не чинит (обычно он лишь подсказывает запуск xfs_repair).

I/O error в dmesg: когда виновато железо или канал

Если в логах доминируют сообщения уровня блока (I/O error, сбросы контроллера, ошибки NVMe/ATA), сначала думайте про носитель/контроллер/бэкенд. Чинить файловую систему, пока устройство продолжает «сыпаться», рискованно: вы ремонтируете структуру на носителе, который продолжает врать или терять записи.

Тактика действий: от «сохранить данные» к «починить»

Рабочая последовательность выглядит так:

1. Зафиксировать симптомы: какие точки монтирования в ro, какие сервисы упали, какие ключевые строки в логах.

2. Оценить риски по I/O и SMART: если есть I/O ошибки и признаки деградации носителя — приоритет на спасение данных и замену диска/тома.

3. Сделать резервную копию критичного, пока чтение ещё возможно (дампы БД, конфиги, пользовательские файлы).

4. Перейти в режим обслуживания (rescue/emergency), чтобы размонтировать раздел и корректно запустить ремонт.

5. Восстановить ФС и только потом возвращать нагрузку, наблюдая логи.

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

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

Подробнее

Emergency mode и rescue: как загрузиться и что делать

Если система не загружается нормально или корень смонтирован ro, вы часто попадаете в emergency/rescue. Ключевая цель: минимизировать запись на диск и добиться состояния, когда проблемный раздел можно размонтировать для проверки.

Проверяем, что именно мешает загрузке

systemctl --failed
journalctl -xb --no-pager | tail -n 200

Иногда emergency вызван не самой ФС, а ошибкой в /etc/fstab. Но даже при проблемах ФС этот вывод помогает понять контекст: что именно отвалилось и на каком устройстве.

Временный remount в rw: только когда осознанно

Иногда нужно срочно поправить конфиг или вытащить данные. Делайте это только если понимаете риск: при реальном повреждении ФС или при I/O ошибках любые записи повышают шанс усугубления.

mount -o remount,rw /

Чтобы снова остановить запись:

mount -o remount,ro /

remount не лечит файловую систему. Это только переключение режима монтирования. «Правка на живую» оправдана в основном для краткого спасения данных/диагностики.

Проверка носителя: SMART (HDD/SSD) и NVMe

Перед «ремонтом» ext4/XFS полезно понять, не умирает ли сам носитель. Даже на виртуальных дисках это важно: I/O ошибки могут указывать на проблемы бэкенда или деградацию на хосте.

SATA/SAS: smartctl

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

Тревожные признаки: рост переназначенных и pending-секторов, ошибки чтения/записи, провал self-test, а также рост CRC-ошибок (иногда это кабель/контакт, но результат для ФС тот же).

NVMe: nvme smart-log

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

Смотрите на media_errors, num_err_log_entries, unsafe_shutdowns, percentage_used и критические предупреждения.

Отдельно про «регулярную гигиену» SSD: TRIM и корректные опции монтирования. Если тема актуальна, пригодится материал про fstrim/discard и обслуживание SSD на Linux.

Восстановление ext4: fsck (правильно и безопасно)

Для ext4 базовое правило: fsck запускается на размонтированном разделе. Если это корень, проще всего загрузиться в rescue/live или использовать режим обслуживания, где корень проверяется до полноценного поднятия системы.

1) Находим проблемный раздел

lsblk -f
blkid
findmnt -no SOURCE /

2) Размонтируем (если это не корень) и запускаем fsck

umount /dev/sdXN
fsck -f -y /dev/sdXN

Что означают опции:

• -f — принудительная проверка.

• -y — автоматически отвечать «yes» на исправления. Удобно для удалённой работы, но на критичных системах иногда лучше интерактивно, чтобы понимать, что именно правится.

3) Если это LVM/RAID/устройство dm-*

Проверка идёт по блочному устройству, где находится ФС (например, /dev/mapper/vg-root):

fsck -f -y /dev/mapper/vg-root

4) После fsck

Монтируем обратно и убеждаемся, что ошибка не повторяется:

mount -a
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /
dmesg -T | tail -n 100

Если ext4 снова быстро уходит в ro, это часто означает, что проблема ниже уровня ФС: I/O ошибки, деградация диска, нестабильный бэкенд.

Восстановление XFS: xfs_repair и когда нужен -L

XFS устроена иначе: «обычный fsck» не применяется. Если XFS поймала ошибку, сделала shutdown и стала read-only, дальше нужен xfs_repair на размонтированном томе.

1) Размонтируем и запускаем repair

umount /dev/sdXN
xfs_repair /dev/sdXN

2) Если xfs_repair требует сбросить лог (ключ -L)

Иногда ремонт требует обнулить журнал. Это делается так:

xfs_repair -L /dev/sdXN

xfs_repair -L может привести к потере последних неподтверждённых операций (того, что было только в журнале). Но после серьёзного сбоя это нередко единственный способ поднять том.

3) Монтируем и проверяем, что система стабилизировалась

mount /dev/sdXN /mnt
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /mnt
dmesg -T | tail -n 100

Почему проблема возвращается после «успешного» ремонта

Если вы сделали fsck или xfs_repair, система ожила, но через пару часов снова «Read-only file system», обычно причина одна из следующих:

• Носитель продолжает деградировать: новые I/O error, SMART/NVMe показатели ухудшаются.

• Проблемы в подсистеме хранения: контроллер, бэкенд, ошибки на хосте, нестабильность виртуализации.

• Ошибка проявляется под нагрузкой: например, БД генерирует много sync-операций, и сбой всплывает именно при пике записи.

• Повторяющиеся «грязные» перезагрузки: растёт unsafe_shutdowns у NVMe, в журнале заметны внезапные ребуты.

В таких сценариях ремонт ФС без устранения корня даёт лишь краткую передышку. Часто правильнее заранее подготовить перенос данных и аккуратно расширять/мигрировать хранилище. Если вы параллельно увеличиваете диск, пригодится инструкция про расширение диска и файловой системы (growpart/resize).

Чек-лист: что собрать для разбора инцидента

Чтобы быстро передать задачу коллегам или поддержке и не потерять контекст, соберите (в текстовый файл) минимум:

• Вывод findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS / и других важных точек монтирования.

• Фрагмент dmesg -T вокруг момента remount ro и первых I/O ошибок.

• journalctl -k -b и journalctl -b (последние 300–500 строк).

• SMART/NVMe: smartctl -a или nvme smart-log.

• Информацию о блочных устройствах: lsblk -f, blkid.

Профилактика: как реже ловить remount ro

• Регулярные бэкапы с проверкой восстановления (не только «копия есть», но и «восстановление поднимается»).

• Мониторинг SMART/NVMe: алерты на рост ошибок и на percentage_used для NVMe.

• Контроль свободного места и ротация логов.

• План миграции: если носитель начал сыпаться, переносите заранее, а не в пожарном режиме.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Короткий сценарий «что делать прямо сейчас»

1. Подтвердить ro: findmnt, mount.

2. Найти первопричину: dmesg -T, journalctl -k -b (ищем ext4/xfs ошибки и I/O).

3. Проверить носитель: smartctl или nvme smart-log.

4. Если подозрение на проблемы ниже уровня ФС — сначала спасать данные чтением и планировать замену диска/тома.

5. Если похоже на сбой ФС без деградации диска — уходить в rescue/emergency, размонтировать и запускать fsck (ext4) или xfs_repair (XFS).

6. После восстановления наблюдать логи: если ошибки возвращаются — искать причину ниже уровня ФС.

Если хотите, могу подсказать по вашему конкретному кейсу: пришлите вывод findmnt -no SOURCE,FSTYPE,OPTIONS / и 50–100 строк из dmesg -T вокруг ошибки. По ним обычно сразу видно, это больше про ремонт ext4/XFS или про умирающий носитель/бэкенд.