【银河麒麟高级服务器操作系统】磁盘只读问题分析

系统环境及配置

系统环境	物理机/虚拟机/云/容器	虚拟机
网络环境	外网/私有网络/无网络	私有网络
硬件环境	机型	KVM Virtual Machine
	处理器	Kunpeng-920
	内存	32 GiB
	整机类型/架构	arm64
	固件版本	EFI Development Kit II / OVMF
软件环境	具体操作系统版本	银河麒麟高级服务器操作系统 Kylin Linux Advanced Server release V10 (Halberd)
	内核版本	4.19.90-89.11.v2401.ky10.aarch64

现象描述

服务器磁盘变成只读，vda磁盘挂载到/data磁盘变只读，/data目录无法创建文件，需要分析EXT4文件系统变为只读原因。

分析过程

查看系统存储情况，如下图所示：

查看var/log/messages-20241212日志，在12月10日 11:45:56，vda1出现I/O错误。

Dec 10 11:45:56 clickhouse kernel: [ 3541.839637] print_req_error: I/O error, dev vda, sector 6287898104 Dec 10 11:45:56 clickhouse rasdaemon[969]: rasdaemon: diskerror_eventstore: 0xaaada9e69ff8 //  由于发生了I/O错误，EXT4文件系统中止了其日志操作。日志是EXT4保证文件系统一致性的关键机制，中止日志意味着文件系统可能处于不一致状态。 Dec 10 11:45:56 clickhouse kernel: [ 3541.839790] Aborting journal on device vda1-8. Dec 10 11:45:56 clickhouse rasdaemon[969]: rasdaemon: register inserted at db Dec 10 11:45:56 clickhouse rasdaemon[969]:          <idle>-0     [001]     0.000354: block_rq_complete:    2024-12-10 11:45:56 +0800 253:0 WS () 6287898104 + 8 [I/O error] // 进一步确认了日志被中止 Dec 10 11:45:56 clickhouse kernel: [ 3541.916239] EXT4-fs error (device vda1): ext4_journal_check_start:61: comm ext4lazyinit: Detected aborted journal // 为了防止进一步的数据损坏，内核将文件系统/dev/vda1重新挂载为只读模式。 Dec 10 11:45:56 clickhouse kernel: [ 3541.919341] EXT4-fs (): Remounting filesystem read-only

在Dec 11 10:06:01, Dec 11 10:09:49, Dec 11 10:19:34这三个时间点，尝试重新挂载失败。

//试重新挂载文件系统/dev/vda1为读写模式，但由于底层仍然存在问题，挂载操作被用户强制中止。这表明问题并没有自动恢复。 Dec 11 10:06:01 clickhouse kernel: [83947.454615] EXT4-fs error (device vda1): ext4_remount:5643: comm mount: Abort forced by user Dec 11 10:09:49 clickhouse kernel: [84175.222579] EXT4-fs error (device vda1): ext4_remount:5643: comm mount: Abort forced by user Dec 11 10:19:34 clickhouse kernel: [84759.838210] EXT4-fs error (device vda1): ext4_remount:5643: comm mount: Abort forced by user //EXT4记录了自上次文件系统检查 (fsck) 以来发生的错误数量为4 Dec 12 10:36:57 clickhouse kernel: [  310.239571] EXT4-fs (vda1): error count since last fsck: 4 // initial error at time ...和last error at time ...: 记录了首次和最后一次错误的时间戳，与之前的日志记录一致 Dec 12 10:36:57 clickhouse kernel: [  310.239603] EXT4-fs (vda1): initial error at time 1733802356: ext4_journal_check_start:61 Dec 12 10:36:57 clickhouse kernel: [  310.239609] EXT4-fs (vda1): last error at time 1733883574: ext4_remount:5643

查看var/log/messages-20241214日志，在12月12日 14:06:33第二个磁盘vdb出现I/O错误。

Dec 12 14:06:33 clickhouse kernel: [  216.739315] print_req_error: I/O error, dev vdb, sector 7067803944 // 在尝试写入数据到/dev/vdb上的多个inode时发生了I/O错误。这表明写操作失败，可能会导致数据丢失或损坏。 Dec 12 14:06:33 clickhouse kernel: [  216.739340] EXT4-fs warning (device ): ext4_end_bio:325: I/O error 10 writing to inode 110434210 (offset 0 size 0 starting block 883475494) ... (大量的 ext4_end_bio 错误) ... Dec 12 14:06:33 rasdaemon[968]: rasdaemon: diskerror_eventstore: 0xaaae75459ff8 // JBD2是EXT4的日志组件，表明在刷新数据到磁盘时也遇到了I/O错误。 Dec 12 14:06:33 kernel: [  216.780921] JBD2: Detected IO errors while flushing file data on vdb-8

分析以上日志，可以得出以下结论：

问题根源是底层存储的I/O错误，print_req_error和rasdaemon的报警都指向了底层的硬件或存储层面的问题，而且/dev/vda1和/dev/vdb都出现了I/O错误，说明不是单个磁盘或文件系统的问题。

文件系统损坏是I/O错误的直接结果，由于底层存储无法正常工作，导致EXT4文件系统的日志无法正常写入，最终导致日志中止和文件系统被标记为只读。ext4_journal_check_start和ext4_end_bio的错误信息也证实了这一点。

分析结论

综合分析，虚拟机系统内部原因可能性很低，虽然虚拟机内部的驱动程序错误或配置问题可能导致I/O问题，但同时影响到两个不同的虚拟磁盘，并且有print_req_error和rasdaemon的硬件错误报告，这种可能性非常之低。虚拟机环境底层的存储资源是由云平台或宿主机提供的，以下两种情况的可能性最高：

1.  宿主机存储或者存储网络等硬件可能存在故障或性能问题，导致提供给虚拟机的虚拟磁盘出现I/O错误。
2. 云平台的存储服务可能存在问题，导致虚拟机的存储访问出现问题。

解决方案

根据提供的日志分析，虚拟机EXT4文件系统损坏的主要原因是底层存储的 I/O 错误。问题很可能出在宿主机的硬件层面或者云平台的存储服务上，需要进一步排查底层存储问题。