1. 故障现象初探当磁盘突然变成哑巴那天早上刚到办公室就接到运维同事的紧急电话数据盘突然不能写了登录服务器一看果然/data目录下所有写入操作都报Read-only file system错误。这种场景对于使用银河麒麟高级服务器操作系统的管理员来说就像突然发现自己的笔记本变成了只能看不能改的记事本。通过mount | grep data命令确认/dev/vda1确实以只读模式挂载在/data目录。这时候千万别急着执行mount -o remount,rw /data——我见过太多同行在这个环节直接操作结果导致更严重的数据不一致问题。正确的做法是先记录当前状态# 查看磁盘挂载状态 mount | grep vda1 # 检查文件系统错误计数 dmesg | grep -i ext4.*error在日志中发现了关键线索系统在三个不同时间点Dec 10 11:45:56、Dec 11 10:06:01、Dec 12 14:06:33连续出现I/O错误。特别是第一条日志print_req_error: I/O error, dev vda, sector 6287898104就像医生看到的第一个异常指标暗示着底层存储可能出了问题。2. 日志侦探工作从蛛丝马迹找真相2.1 内核日志的摩斯密码银河麒麟系统的/var/log/messages就像一本病例记录。我习惯用时间倒序查看最新异常grep -A 10 -B 5 I/O error /var/log/messages发现的关键日志序列非常典型先是硬件层报错print_req_error接着EXT4文件系统中止日志Aborting journal最后系统自动重新挂载为只读Remounting filesystem read-only这种递进关系就像多米诺骨牌硬件I/O错误 → 文件系统日志中断 → 保护性只读挂载2.2 rasdaemon的硬件诊断报告很多管理员会忽略这个神器——银河麒麟预装的rasdaemon工具。它记录的硬件错误事件往往能直指问题核心ras-mc-ctl --errors在案例中看到diskerror_eventstore记录这相当于存储设备的体检异常项。特别是当多个磁盘vda和vdb同时报错时基本可以排除单个磁盘故障的可能性。3. 深度排查从现象到本质的推理3.1 排除法锁定问题范围面对EXT4只读问题我通常会画个排查矩阵排查方向检查点本案例情况文件系统损坏fsck检查是结果而非原因内核BUG查看已知issue和补丁多磁盘同时异常概率低硬件故障rasdaemonsmartctl有明确硬件错误事件存储链路问题多路径状态、HBA卡日志虚拟机环境需检查底层存储资源耗尽df -i、dmesg内存压力无相关日志佐证本案最可疑的是两个独立磁盘同时出现I/O错误。就像办公室所有打印机突然卡纸大概率是纸张供应商出了问题。3.2 云环境特殊考量在KVM虚拟化环境下需要特别注意宿主机存储是否使用RAIDmegacli -PDList -aAll查看物理磁盘状态存储网络是否正常ethtool -S检查网卡错误计数云平台是否有存储告警联系云厂商提供底层监控数据曾有个经典案例某云平台宿主机NVMe SSD固件缺陷导致所有虚拟机磁盘间歇性I/O错误。这种问题在虚拟机内部再怎么排查都是徒劳。4. 修复方案与操作指南4.1 紧急恢复步骤当确认是底层存储问题后建议按此流程操作# 1. 备份关键数据即使只读 rsync -av /data /backup/ # 2. 联系云厂商或硬件团队处理底层问题 # 3. 问题解决后强制检查文件系统 umount /data fsck -y /dev/vda1 # 4. 重新挂载 mount -o defaults /dev/vda1 /data特别注意在云环境中有个隐藏技能——迁移实例到其他宿主机。这相当于给虚拟机换了台新主机往往能立即解决底层硬件问题。4.2 长期预防措施根据这次教训我给团队制定了新的监控策略新增Zabbix监控项vfs.dev.read_errors[/dev/vda] vfs.dev.write_errors[/dev/vdb]配置日志监控规则# /etc/rsyslog.d/kernel-errors.conf :msg, contains, EXT4-fs error /var/log/ext4_errors.log定期健康检查脚本#!/bin/bash for dev in $(lsblk -dn -o NAME); do smartctl -H /dev/$dev | grep -q PASSED || \ echo Disk $dev SMART failure! done5. 技术原理深潜EXT4的自我保护机制EXT4文件系统设计有个精妙的熔断机制——当检测到不可恢复错误时会自动切换为只读模式。这就像电路中的保险丝宁可中断服务也要保护数据。关键触发条件包括日志写入失败JBD2错误超级块校验失败关键元数据更新失败底层设备返回I/O错误在银河麒麟的4.19内核中这个逻辑主要在fs/ext4/super.c的ext4_handle_error()函数实现。有趣的是这个保护机制有时反而会过度反应——在临时性网络存储抖动时也可能触发只读。这时候就需要在挂载选项中加入errorscontinue但我不建议生产环境这样做数据一致性远比可用性重要。6. 高阶排查工具链除了基本命令这些工具能提供更多维度信息blktrace像X光一样透视IO路径blktrace -d /dev/vda -o trace.dat blkparse trace.dat | grep -i erroriostat实时监控IO异常iostat -xmdz 1重点观察await和%util指标突然飙升bcc工具集动态追踪内核行为/usr/share/bcc/tools/biosnoop记得去年处理过一例NVMe磁盘超时问题就是用bcc工具发现中断处理延迟超过500ms最终定位到CPU电源管理导致的C-state问题。7. 虚拟化环境特别注意事项在银河麒麟作为虚拟机运行时这些细节需要特别关注磁盘前端驱动选择Virtio-blk性能最好但可能丢IOSCSI更稳定但延迟略高检查磁盘缓存模式cat /sys/block/vda/queue/write_cache建议云环境使用writeback而非writethrough警惕信号丢失现象 某些云平台底层存储故障时虚拟机内反而看不到任何错误直到数据损坏才发现。这时候需要定期做dd if/dev/zero of/data/testfile bs1M count1024 convfsync每次故障排查都像侦探破案从表面的EXT4只读现象到最终定位到云平台存储集群的固件缺陷这中间需要严谨的逻辑推理和全面的技术视野。建议每位系统管理员都建立自己的诊断决策树把经验转化为系统化的排查流程。