OpenZFS中ZED服务因udev设备父节点检查引发的崩溃问题分析

问题背景

在OpenZFS 2.2.6版本中，ZFS事件守护进程(ZED)在特定场景下会出现崩溃现象。该问题主要发生在Linux内核6.11.5环境下，当系统触发udev事件时（如执行udevadm trigger -s block命令），ZED服务会因断言失败而异常终止，并生成核心转储文件。

技术细节分析

通过核心转储分析，我们发现崩溃发生在udev_device_get_sysattr_value()函数中。深入调查发现，问题根源在于ZED处理设备事件时的父设备检查逻辑存在缺陷。

具体来说，在dev_event_nvlist()函数中，代码会尝试获取设备的父设备信息（如/dev/sda1的父设备/dev/sda），但对于某些特殊设备类型（如DM-CRYPT-PLAIN加密设备），这些设备可能没有父设备节点。原始代码未对此情况进行判断，直接尝试访问父设备的"size"属性，导致断言失败。

问题复现条件

该问题会在以下条件同时满足时触发：

1. 系统使用DM-CRYPT-PLAIN等无父设备的特殊块设备
2. 执行udev事件触发操作
3. ZED服务正在运行并监控设备事件

解决方案

修复方案相对简单：在访问父设备属性前增加对父设备指针的非空检查。修改后的核心代码如下：

struct udev_device *parent_dev = udev_device_get_parent(dev);
if (parent_dev != NULL && (value = udev_device_get_sysattr_value(parent_dev, "size")) != NULL) {
    uint64_t numval = DEV_BSIZE;
    numval *= strtoull(value, NULL, 10);
    (void) nvlist_add_uint64(nvl, DEV_PARENT_SIZE, numval);
}

延伸思考

在问题排查过程中还发现一个有趣现象：DM-CRYPT-PLAIN设备的事件触发模式与多路径设备类似，都会先收到ADD事件，随后收到包含完整信息的CHANGE事件。这引发了一个更深层次的问题思考：是否应该像处理多路径设备那样，将这类设备的EC_DEV_STATUS事件当作EC_DEV_ADD事件处理？这可能需要进一步的讨论和测试验证。

影响评估

该问题主要影响：

1. 使用加密存储或特殊设备配置的环境
2. 频繁触发udev事件的系统
3. 依赖ZED进行自动化管理的ZFS存储方案

最佳实践建议

对于使用特殊块设备的环境，建议：

1. 及时应用该问题的修复补丁
2. 监控ZED服务的稳定性
3. 在自动化脚本中增加对ZED服务状态的检查
4. 考虑对特殊设备类型的事件处理进行定制化配置

该问题的修复不仅解决了ZED崩溃的问题，也为处理无父设备的特殊块设备提供了更健壮的代码基础。