那天下午我在排查一个存储性能问题时在服务器上敲下lsblk命令看到一列/dev/dm-0、/dev/dm-1的设备名。这些设备不像普通的/dev/sda那样直接对应物理磁盘而是像一层“中间商”在物理设备和文件系统之间架起了一座桥。这就是 Linux 内核中的 DeviceMapperDM框架在发挥作用。你可能每天都在用它却未必意识到它的存在——无论是 Docker 使用的存储驱动、LVM 的逻辑卷还是 Android 系统的分区加密背后都是这套框架在支撑。但 DM 框架真正厉害的地方不是它能创建虚拟块设备而是它把“策略”和“机制”彻底分离的架构思想。用户空间负责定义“要做什么”比如加密、条带化、快照内核空间只负责“怎么做”高效的 IO 转发。这种设计让 DM 成为了 Linux 存储栈中最具扩展性的基础设施之一。1. 先搞清楚 DM 框架解决的不是“虚拟化”而是“策略与机制分离”很多人第一次接触 DM 时会把它简单理解为一个“虚拟块设备”的创建工具。这个理解没错但只看到了表面。DM 真正要解决的是存储管理中长期存在的矛盾策略的灵活性与内核机制的稳定性如何兼顾。1.1 为什么存储功能不能全部写死在内核里想象一下如果每种存储功能加密、压缩、快照、条带化都以内核模块的形式硬编码会出现什么情况功能膨胀内核体积会急剧增大每个新功能都需要重新编译内核或加载模块兼容性问题不同存储功能之间可能存在冲突调试困难升级困难修复一个存储功能的 bug 可能需要重启整个系统DM 框架通过“插件化”的设计规避了这些问题。它在内核中只保留最核心的 IO 转发机制所有具体的处理逻辑都以 Target Driver 的形式动态加载。// 概念性的代码结构展示 DM 的插件化设计 struct target_type { const char *name; struct module *module; int (*ctr)(struct dm_target *ti, unsigned int argc, char **argv); void (*dtr)(struct dm_target *ti); int (*map)(struct dm_target *ti, struct bio *bio); // ... 其他操作函数 };每个 Target Driver 只需要实现自己的ctr构造函数、dtr析构函数和mapIO 映射等几个关键接口就能嵌入到 DM 框架中。1.2 DM 的三层对象模型映射关系的本质DM 框架的核心是三个对象概念理解了它们就理解了 DM 的工作方式Mapped Device映射设备用户看到的虚拟块设备如/dev/dm-0本身不存储数据只是 IO 请求的入口和出口Target Device目标设备实际存储数据的物理设备或另一个虚拟设备可以是单个磁盘、分区甚至是另一个 DM 设备Mapping Table映射表定义 Mapped Device 与 Target Device 之间的映射关系记录逻辑偏移→物理偏移的对应关系这种设计让 DM 设备可以层层堆叠形成一棵设备树。比如一个加密的条带化存储最上层是加密 DM 设备中间是条带化 DM 设备最下层才是物理磁盘。2. 从零构建一个 DM 设备理解内核与用户空间的分工要真正理解 DM 框架最好的方式是通过它的创建过程。这个过程清晰地展示了策略在用户空间机制在内核空间的设计哲学。2.1 第一步用户空间准备映射信息DM 设备的创建从用户空间开始主要通过dmsetup工具或直接通过/dev/mapper/control设备文件进行通信。# 创建线性映射的示例 echo 0 1024 linear /dev/sdb1 0 | dmsetup create my_volume这个命令告诉内核创建一个名为my_volume的 DM 设备该设备的前 1024 个扇区映射到/dev/sdb1的从 0 开始的扇区。用户空间的工作就是准备这样的映射表它定义了要做什么但不关心怎么做。2.2 第二步内核初始化映射设备当内核收到创建请求后会依次执行以下操作分配 mapped_device 结构体初始化锁、内存池、请求队列等资源创建对应的块设备如/dev/dm-0解析并验证映射表检查映射表语法的正确性验证目标设备是否存在且可访问确保映射范围不重叠、不越界加载对应的 Target Driver根据映射表类型linear、crypt、striped 等加载相应模块调用 Target Driver 的构造函数初始化私有数据这个过程的关键在于内核只做最基础的验证具体的映射逻辑完全交给 Target Driver。2.3 第三步建立 IO 转发通路映射表加载完成后DM 设备就进入了可工作状态。当有 IO 请求到达时// 简化的 IO 处理流程 static int dm_submit_bio(struct bio *bio) { struct mapped_device *md bio-bi_bdev-bd_disk-private_data; struct dm_target *ti; sector_t sector bio-bi_iter.bi_sector; // 根据扇区号查找对应的 target ti dm_table_find_target(md-map, sector); if (!ti) return -EIO; // 调用 target 的 map 方法处理 bio return ti-type-map(ti, bio); }这个流程体现了 DM 框架的巧妙之处内核只知道要找哪个 target但具体怎么处理 bio完全由 Target Driver 决定。3. 深入 Target Driver看 DM 如何实现不同存储功能Target Driver 是 DM 框架的技能包每个 Driver 实现一种特定的存储功能。了解几个典型的 Driver就能明白 DM 的扩展性有多强。3.1 dm-linear最简单的线性映射dm-linear是最基础的 Target Driver它实现简单的线性地址映射。它的映射逻辑非常简单映射规则逻辑扇区 → 物理扇区 偏移量这种映射虽然简单但却是 LVM逻辑卷管理的基础。通过组合多个dm-linear设备可以实现磁盘空间的动态扩展和收缩。3.2 dm-crypt透明的磁盘加密dm-crypt实现了透明的磁盘加密它在 IO 路径上自动进行加密/解密操作// 简化的加密处理流程 static int crypt_map(struct dm_target *ti, struct bio *bio) { struct crypt_config *cc ti-private; if (bio_data_dir(bio) WRITE) { // 写操作加密数据 crypto_skcipher_encrypt(cc-tfm, bio-bi_io_vec-bv_page); } else { // 读操作解密数据 crypto_skcipher_decrypt(cc-tfm, bio-bi_io_vec-bv_page); } // 将 bio 重定向到底层设备 bio_set_dev(bio, cc-dev-bdev); return DM_MAPIO_REMAPPED; }这种设计的好处是上层应用完全感知不到加密的存在可以像使用普通磁盘一样使用加密卷。3.3 dm-verityAndroid 的安全基石dm-verity是 Android 系统安全的重要组件它通过默克尔树Merkle Tree验证块设备的完整性构建阶段计算每个数据块的哈希构建哈希树验证阶段读取数据时验证对应的哈希值是否匹配防篡改任何对数据的修改都会导致哈希验证失败这种机制确保了系统分区的完整性防止恶意软件修改系统文件。4. DM 框架的 IO 流向理解 bio 的克隆与转发机制DM 框架最精妙的部分在于它对 IO 请求的处理方式。理解 bio 的流转过程是理解 DM 性能特征的关键。4.1 bio 的生命周期从提交到完成当一个 bio 提交到 DM 设备时它可能经历以下旅程原始 bio 到达 mapped device应用层发起的 IO 请求封装在 bio 结构中包含目标设备、扇区范围、数据缓冲区等信息bio 克隆与转发DM 根据映射表创建 bio 的克隆clone每个克隆指向下层 target device 的相应位置原始 bio 被暂停等待克隆 bio 完成分层处理克隆 bio 被发送到下层设备如果下层也是 DM 设备过程递归进行最终到达物理设备完成实际 IO 操作完成回调物理设备完成 IO 后沿设备树向上传递完成事件每层可以执行自己的完成处理如错误处理、统计更新最终唤醒原始 bio向应用层返回结果4.2 性能考量bio 分裂与合并策略DM 框架需要处理各种复杂的映射场景这对 bio 的分裂与合并提出了挑战何时需要分裂 bio当 bio 跨越多个 target 的边界时当 bio 大小超过下层设备的最大限制时当 target driver 有特殊对齐要求时如何优化性能尽量保持 bio 的连续性减少分裂次数在适当的时候合并相邻的小 bio使用 mempool 避免频繁的内存分配这些优化策略直接影响 DM 设备的性能表现特别是在高并发 IO 场景下。5. 实战排查 DM 设备问题的系统化方法在实际使用中DM 设备可能出现各种问题性能下降、设备无法创建、IO 错误等。掌握系统化的排查方法至关重要。5.1 基础信息收集了解 DM 设备状态首先通过标准工具了解 DM 设备的整体情况# 查看所有 DM 设备 dmsetup ls # 查看具体设备的映射表 dmsetup table # 查看设备依赖关系 dmsetup deps # 查看设备状态信息 dmsetup status这些命令可以快速确认 DM 设备的基本配置是否正确。5.2 IO 路径分析追踪 bio 流转当出现性能问题或 IO 错误时需要深入 IO 路径检查请求队列cat /sys/block/dm-0/queue/scheduler cat /sys/block/dm-0/queue/nr_requests监控 IO 统计iostat -x 1 # 查看设备利用率、等待时间 cat /sys/block/dm-0/stat # 查看详细的 IO 计数使用 blktrace 深度追踪blktrace -d /dev/dm-0 -o trace blkparse trace -i trace.blktrace.* parsed.txt5.3 常见问题模式与解决方案根据经验DM 设备的问题通常有几种典型模式模式一设备创建失败原因映射表语法错误、目标设备不存在、权限不足排查检查 dmesg 日志、验证目标设备状态、确认用户权限模式二性能突然下降原因底层设备故障、映射表过于复杂、资源竞争排查检查底层设备 SMART 状态、简化映射关系、调整 IO 调度器模式三随机 IO 错误原因物理介质损坏、target driver bug、内存损坏排查运行硬件诊断、更新内核版本、检查内存错误6. 从使用到贡献DM 框架的演进与社区生态DM 框架经过多年的发展已经形成了成熟的社区生态。了解这个生态有助于更好地使用和贡献于 DM。6.1 主要应用场景与相关项目DM 框架支撑了许多重要的开源项目LVM2Linux 逻辑卷管理基于 dm-linear 和 dm-stripedDocker使用 dm-thinp 实现存储驱动早期版本Android使用 dm-verity 和 dm-crypt 保证系统安全DRBD分布式复制块设备与 DM 结合使用这些项目反过来也推动了 DM 框架的功能完善和性能优化。6.2 如何参与 DM 开发如果你对 DM 框架感兴趣可以从以下几个方面入手阅读代码从简单的 target driver如 dm-zero开始理解基本架构调试现有功能复现和修复已知 bug熟悉代码流程实现简单 target尝试实现一个功能简单的 target driver参与代码审查学习社区的代码标准和最佳实践Linux 内核的邮件列表是主要的开发交流平台参与讨论前建议先阅读现有的讨论记录。6.3 DM 框架的未来方向随着存储技术的发展DM 框架也在不断演进性能优化更好的多队列支持、更高效的 bio 处理新功能支持ZNS分区设备、计算存储等新硬件特性安全增强更灵活的加密策略、更细粒度的访问控制容器集成为容器环境优化的轻量级存储方案DM 框架的成功证明了一个道理好的基础设施不是功能最多的而是扩展性最强的。它通过清晰的接口定义和灵活的可插拔架构在保持内核稳定的同时为用户空间的创新提供了无限可能。真正理解 DM 框架的价值不在于记住多少数据结构或函数调用而在于体会这种机制与策略分离的设计思想。这种思想不仅适用于存储系统也适用于任何需要平衡灵活性和稳定性的软件架构。