生产服务器出现 Read-only file system 时，应用会无法写日志、数据库无法落盘、容器创建失败。Linux 把文件系统重新挂载为只读，往往是在保护数据，不能直接把它当成普通权限问题。
一、先确认影响范围
记录故障时间、受影响挂载点和最先报错的服务，不要立即重启。
date
uptime
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
mount | grep ' ro[,)]'
df -hT
df -ih测试时只在业务允许的目录创建临时文件：
touch /path/to/mount/.rw-test如果只有一个数据盘只读，系统盘仍正常，问题多半集中在对应块设备或文件系统。如果根目录只读，应优先保留远程会话并准备控制台入口。
二、立即收集内核证据
dmesg -T | tail -n 200
journalctl -k --since '-30 min' --no-pager
journalctl -p err..alert --since '-30 min' --no-pager
dmesg -T | grep -Ei 'I/O error|EXT4-fs|XFS|Buffer I/O|blk_update|nvme|reset|read-only'常见信息包括磁盘 I/O error、EXT4 journal abort、XFS metadata error、NVMe timeout 和 SCSI reset。把原始日志保存到其他正常磁盘或远端，重启后部分信息可能丢失。
三、定位设备与存储链路
lsblk -f
findmnt /path/to/mount
ls -l /dev/disk/by-id/
pvs; vgs; lvs
cat /proc/mdstat
multipath -ll如果是云盘，还要检查云平台磁盘事件、吞吐和 IOPS；如果是虚拟机，检查宿主机和存储阵列。物理盘可读取 SMART 信息，但不要对异常磁盘做长时间压力测试：
smartctl -a /dev/sdX
nvme smart-log /dev/nvme0四、应急决策
情况 A：底层存储仍有 I/O 错误
不要反复执行 mount -o remount,rw。即使暂时成功，继续写入也可能扩大损坏。应先停止写入型服务，切流或启用备用节点，联系存储侧处理，并确认最近备份。
情况 B：存储已经稳定，仅文件系统保护性只读
先停止相关应用，确认无持续错误后再评估临时重新挂载：
mount -o remount,rw /mountpoint重新挂载只适合明确判断底层正常且需要短时恢复的场景。恢复后若再次只读，应立即停止写入并安排离线修复。
五、离线修复文件系统
修复前确认设备名、文件系统类型和备份。文件系统检查不能直接对正在读写的挂载点执行。
EXT4
进入救援模式或卸载数据盘后执行：
umount /dev/mapper/vg-data
fsck -f /dev/mapper/vg-data不要在不理解影响时直接使用 fsck -y，它会自动确认所有修复动作。
XFS
umount /dev/mapper/vg-data
xfs_repair -n /dev/mapper/vg-data
xfs_repair /dev/mapper/vg-data先用 -n 做只读检查。xfs_repair -L 会清空日志，可能丢失未提交元数据，只能作为最后手段并经过数据风险确认。
六、恢复后的验证
mount /mountpoint
findmnt /mountpoint
touch /mountpoint/.rw-test && rm /mountpoint/.rw-test
dmesg -T | tail -n 100随后按依赖顺序启动服务，检查数据库一致性、应用日志、监控和业务读写。恢复完成不代表故障结束，还要确认磁盘是否需要更换、云盘是否需要迁移。
七、长期治理
监控磁盘错误、文件系统只读、SMART/NVMe 健康、云盘 IOPS 和延迟。
对关键数据盘配置快照、备份及恢复演练。
为虚拟机保留带外控制台，避免根目录只读后无法 SSH。
规范关机、扩容、快照和存储迁移操作。
数据库采用副本或集群，避免单盘故障直接中断业务。
正确顺序是：保护现场、确认底层存储、停止危险写入、离线修复、验证数据，再恢复业务。