解决EXT4-fs error (device dm-0): ext4_lookup 问题

问题

定期检查家用存储服务器的状态，发现dmesg输出信息中包含着和存储相关的报错信息

排查

存储问题不可小视。首先要确定下问题是什么。看起来是ext4文件系统存在文件节点错误，而且一直没有修复。接下来要确定到底是哪个设备出现了问题。通过日志看到是dm-0设备。但是dm-0设备是哪个存储设备呢?

经过查找，得知通过dmsetup ls可以得知device mapper设备与存储卷的对应关系。通过输出卷的名字，得知是搭建的软RAID1设备/dev/md0所对应的存储卷。

首先检查RAID1阵列是否存在问题，通过运行cat /proc/mdstat，发现阵列在重新检查中，并未出现不同步或降级问题。于是可以确认问题出在ext4文件系统本身。

解决

对于ext4分区文件系统中文件节点的错误，fsck一般可以解决。于是接下来首先umount问题卷，接下来fsck /dev/md0，一路按y确认修复操作。再通过mount命令挂载，等待了30分钟后，dmesg不再有文件系统错误出现，问题解决。

复盘

好端端的ext4文件系统怎么就出现错误了呢。分析了下原因，应该有两点。一点是/dev/md0这个RAID1阵列在前段时间出现了其中一块盘跪掉然后替换的情况，期间出现了几次强制断电重启，可能因此留下了文件系统错误。

另外一点，由于这个RAID1阵列并非系统内置设备，为了防止系统不正常启动，所以挂载动作没有放在/etc/fstab中，而是从启动命令中添加了挂载命令语句。两者的差别在于，默认情况下，通过fstab挂载的设备会首先运行fsck检查，再挂载，因此每次一有小问题就会修复，问题不会累积扩大。但是手工挂载并没有检查文件系统，就更容易出问题。

预防

所以接下来又做了一点，在系统启动的挂载脚本执行之前，添加了一行/sbin/fsck -a UUID=xxxxxxxxxxx，这样每次就会先自动检查磁盘，再挂载，防止问题发生。