90%的read-only file system是内核检测异常后的保护性降级，数据通常完好；须先通过dmesg、/proc/mounts和smartctl排查硬件风险，确认安全后再决定remount,rw或fsck修复。
直接告诉你结论：90% 的 Read-only file system 不是硬盘真坏了，而是内核发现异常后主动降级保护——只要没强行写入或格式化，数据基本完好；但修复前必须分清是硬件故障、文件系统损坏，还是配置错误，顺序错了可能把可修变不可逆。
先看是不是被内核强制只读了
内核不会无缘无故设为只读，它是在日志里记了账的。别急着 remount 或 fsck，先查 dmesg：
-
dmesg -T | tail -50，搜EXT4-fs error、XFS: failed、I/O error、end_request、SMART—— 出现任意一个，说明底层有真实异常 -
cat /proc/mounts | grep "ro\|errors="，如果看到errors=remount-ro，就是文件系统出错后被自动挂成只读，属于软件层保护行为 - 再确认当前挂载状态：
mount | grep " / "，输出含(ro,relatime)才是真的只读；若显示(rw,relatime)却仍报错，大概率是进程或容器层做了限制（比如 Docker volume 挂载时用了ro）
检查磁盘硬件是否快挂了
SSD 或 HDD 出现物理问题时，内核会“自作主张”切只读，此时任何写操作都可能加速损坏。必须用 smartctl 直读硬件状态：
- 对 SATA 盘：
smartctl -a /dev/sda，盯住三项：Reallocated_Sector_Ct（重映射扇区数）、Current_Pending_Sector（待重映射扇区）、UDMA_CRC_Error_Count（接口校验错误）——任一非零且持续上升，立刻停写，优先备份 - 对 NVMe 盘：
smartctl -a /dev/nvme0n1，重点看Available_Reserve_Space（剩余备用块）、Media_Wearout_Indicator（磨损百分比）、Critical_Warning字段——若Critical_Warning是0x10或磨损 ≥ 95，这块盘已到寿命终点，禁止运行e2fsck或xfs_repair - 如果
smartctl报Read SMART Data failed: scsi error或直接无响应，基本可判定链路或控制器异常，不是软件问题
能 remount,rw 就别硬上 fsck
很多场景下只是临时保护，没坏文件系统，乱跑 fsck 反而可能引入新损坏：
- 先试：
mount -o remount,rw /（根分区）或mount -o remount,rw /mnt/data（其他挂载点） - 验证是否生效：
touch /tmp/test_rw && rm /tmp/test_rw，成功即解决 - 失败常见原因：
device is busy（有进程正写该分区），用lsof +D /或fuser -v /查占用进程；或/etc/fstab里写死了ro，需编辑该文件并显式改为defaults,rw - 若提示
/dev/sda1 is mounted且拒绝fsck，别输y强行在线修复——这等于拿锤子敲正在运转的齿轮
必须 fsck 时的三个铁律
只有在确认硬件无风险、且 remount,rw 失败后，才考虑修复文件系统：
- 绝对不在线运行：
e2fsck或xfs_repair必须在目标分区 未挂载 状态下执行；无法卸载就进单用户模式、Live CD 或用systemctl rescue - 按类型选工具：
e2fsck -f -y /dev/sda1（ext4/ext3），xfs_repair /dev/sda1（XFS）；混用会直接破坏元数据 - 修复后必须验证：
mount /dev/sda1 /mnt/test && touch /mnt/test/hello，不能只信输出里的clean字样——有些错误修复后仍会触发内核再次 remount-ro
最常被忽略的一点：修复完如果没改 /etc/fstab，下次重启还会只读；而更隐蔽的是内核启动参数里带了 ro（比如 cat /proc/cmdline | grep ro），这种得去改 /etc/default/grub 并 update-grub。硬件没彻底排除前就动手 remount 或 fsck，等于在没关阀门的情况下修漏水管道。
