LVM异常分析

• 环境信息

• 故障描述

云上鲲鹏RH220安装系统麒麟V10sp1-0711镜像后，升级内核版本到4.19.90-24.4，挂sp2的外网源，用yum install安装sp2外网源中的multipath-tools，版本为multipath-tools-0.8.4-6。后端存储使用的是光纤连接的华为存储Oceanstor18500 v5，系统识别到的多路径设备为mpatha，对mpatha做逻辑卷组datavg和逻辑卷datalv。多路径配置文件中没有配置devices项时，系统多路径启动正常；当修改multipath.conf文件中的Devices配置，将path_checker置成“tur”，重启服务器，多路径启动失败，通过mpatha做的lvm状态为not available。/etc/fstab 文件对datdlv设置为开机自动挂载。经过以上操作后，重启系统，出现datalv逻辑卷没有激活导致重启失败。

下面两幅截图为故障时，查询相关存储的信息：

• 问题分析

1. 配置device的差异分析

我们首先查看不配置device时，读取multipath默认配置信息，可以看到path_checker

为tur，如下所示：

将multipath日志级别调到9，可以打印出更详细的日志信息，重启服务器，在message日志中可以看到路径检测方法实际是rdac，而不是tur。如下图所示：

所以我们需要进一步分析path_checker为tur时，为什么会引起多路径异常导致mpatha做的lvm状态为not available。

1. Lvm异常分析

继续分析multipath.conf配置了device信息，path_checker置成“tur”的情况, 根据messages日志，可以看到异常情况下，multipath有“mpatha: setting up map with 4/4 path checkers pending”和“mpatha: Entering recovery mode: max_retries=15”等错误日志，如下图：

进一步观察messages日志信息中multipath相关的信息，如下图所示：

根据日志可以看到，tur state一直是pending状态，直到multipath报错“mpatha: Entering recovery mode: max_retries=15”也是pending状态。

查看multipath源码，tur检测是采用异步的方式，通过pthread_create创建路径检测线程tur_thread来完成的。源码如下图所示：

继续查看tur_thread的实现如下，可以看到代码中的两条写日志，第一条日志“tur checker starting up”出现说明对路径的检测开始，之后调用tur_check接口对设备发送SCSI命令0x00（即TEST UNIT READY）检测路径，最后出现第二条日志“tur checker finished, state up”表明对路径检测完成。

结合messages日志，路径检测达到最大重试次数之后才出现tur_thread中的两条打印，这说明创建该线程后到切换到该线程执行真正的路径检测的时间较长，因为线程是异步执行的，执行时间是不确定的，导致mpatha的状态是异常的，即“MPATH_DEVICE_READY”为0，因此就不会去激活逻辑卷组datavg和逻辑卷datalv，需要重新加载multipath模块或者重新加载路径等方法来修复。

异常情况日志如下，可以看到MPATH_DEVICE_READY”为0，不会去进行激活mpatha上的逻辑卷组和逻辑卷。

正常情况日志可以看到MPATH_DEVICE_READY”为1，而且会激活mpatha上的逻辑卷组和逻辑卷。

结合上述日志和源码分析可以看出问题的根因是tur的异步线程执行时间不可控，导致tur一直处于pending状态。multipath中tur的检测方式有异步和同步两种方式，默认为异步，同步的方式需要用配置参数“force_sync yes”来开启，在代码中的实现如下图，这样会直接调用tur_check接口发送SCSI命令0x00到设备，不再另起线程检测。

三、验证

在客户环境上设置force_sync为yes，配置path_checker为tur，重启服务器，系统正常启动，查看messages日志，可以看到path state为up状态，没有pending状态，MPATH_DEVICE_READY为1，mpatha上的逻辑卷组和逻辑卷也被激活。

四、结论与解决方案

根据以上分析，首先不配置device的情况，分析日志可以看到华为存储默认的多路径检测方法不是tur，而是rdac，rdac的检测方式是同步的，不会起异步线程，因此重启系统正常。其次逻辑卷没有激活的原因是多路径的路径检测选用tur方法时，检测方式是异步的，异步线程执行时间是不确定的，导致路径检测一直处于pending状态，进而导致多路径mpatha的状态MPATH_DEVICE_READY为0，也不会去激活mpatha上的逻辑卷组和逻辑卷。

综上所述，经过日志分析和实验验证，该问题的解决方案为/etc/multipath.conf文件中的defaults部分增加参数“force_sync yes”将tur的检测方式变为同步。检测方式由异步变为同步，tur_check会等待本次检测成功再返回。在当前的使用场景下，可以采用同步检测这种配置方式。