4. 存储介质与接口：HDD/SSD/NVMe特性、块设备抽象、IO栈、驱动层交互
各位同学，今天我们来聊聊存储介质和接口。这个话题，说白了就是数据恢复的“地基”。你想想看，如果连数据怎么存、怎么读都不清楚，那恢复工作就无从谈起。我在做数据恢复的这些年里，遇到过太多因为不了解底层特性而导致恢复失败的案例了。
4.1 HDD/SSD/NVMe 特性：三种介质的“脾气”
先说说机械硬盘（HDD）。这东西我太熟了，早期做恢复时天天跟它打交道。HDD 的核心是磁头和盘片，数据通过磁头改变盘片上的磁畴方向来存储。它的特点是顺序读写快，随机读写慢——因为磁头要寻道，这个物理动作很耗时。
HDD 的关键特性：
- 磁头寻道时间：5-15ms，这是随机读写的瓶颈
- 转速：5400/7200/10000 RPM，转速越高延迟越低
- 坏道：物理坏道不可逆，逻辑坏道可通过低格修复
- 数据覆写：HDD 覆写后原数据理论上可恢复（因为磁畴有残留）
再说固态硬盘（SSD）。SSD 用的是 NAND Flash 闪存颗粒，没有机械部件。它的随机读写性能远超 HDD，但有个致命问题——擦写次数有限。SLC 约 10 万次，MLC 约 3000-10000 次，TLC 约 500-3000 次，QLC 就更少了。
我曾经遇到一个案例，用户 SSD 突然掉盘，数据全丢了。拆开一看，主控芯片烧了。嗯，这里要注意：SSD 的数据恢复比 HDD 难得多，因为主控和固件是绑定的，换了主控也读不出数据。
SSD 的 TRIM 指令： 操作系统删除文件后，会通知 SSD 哪些块可以擦除。一旦 TRIM 执行，数据就真的没了。所以 SSD 数据恢复要“抢时间”，越快越好。
最后是 NVMe。NVMe 不是一种新的存储介质，而是一种接口协议。它基于 PCIe 总线，直接跟 CPU 通信，延迟极低。NVMe SSD 的 4K 随机读写 IOPS 可以达到百万级别，而 SATA SSD 只有几万。
| 特性 | HDD | SATA SSD | NVMe SSD |
|---|---|---|---|
| 接口 | SATA/SAS | SATA | PCIe M.2/U.2 |
| 顺序读 | ~200 MB/s | ~550 MB/s | ~7000 MB/s |
| 随机读 (4K) | ~1 MB/s | ~100 MB/s | ~1000 MB/s |
| 延迟 | ~10ms | ~0.1ms | ~0.01ms |
| 数据恢复难度 | 中等 | 高 | 极高 |
4.2 块设备抽象：操作系统眼中的存储
操作系统不关心你用的是 HDD 还是 SSD，它只看到“块设备”。块设备是一个抽象概念，把存储介质抽象成一个个固定大小的块（通常是 512 字节或 4KB）。
我个人习惯把块设备想象成一个巨大的数组：block[0]、block[1]……每个元素可以独立读写。文件系统就建立在这个抽象之上，管理这些块的分配和回收。
块设备 vs 字符设备： 块设备可以随机访问（seek），字符设备只能顺序访问（比如键盘、鼠标）。数据恢复主要跟块设备打交道。
在 Linux 中，块设备通过 /dev/sda、/dev/nvme0n1 这样的设备文件暴露给用户空间。你可以用 dd 命令直接读写块设备：
# 读取块设备的前 1MB 数据
dd if=/dev/sda of=/tmp/dump.bin bs=512 count=2048
# 跳过前 100 个块，读取第 101 个块
dd if=/dev/sda of=/tmp/block101.bin bs=512 skip=100 count=1为什么要有块设备抽象？说白了就是为了解耦。文件系统不需要知道底层是 HDD 还是 SSD，它只调用块设备接口。这样文件系统可以通用，换硬盘也不用改代码。
4.3 IO 栈：数据从应用到磁盘的旅程
数据从应用程序到磁盘，要经过一个复杂的 IO 栈。我画个图帮你理解：
你看，数据从 App 出发，经过系统调用、VFS、具体文件系统，最后到达块设备层。块设备层下面还有驱动层，再往下才是物理介质。
在数据恢复中，我们经常要绕过文件系统，直接操作块设备层。比如用 ddrescue 工具，就是直接读块设备，跳过文件系统的缓存和错误处理。
IO 栈的关键点：
- Page Cache：文件系统层和块设备层之间还有 Page Cache，读数据时先查缓存
- IO 调度：块设备层有 IO 调度器，合并相邻请求、排序，提高效率
- Direct IO：绕过 Page Cache，直接读写块设备，数据恢复常用
4.4 驱动层交互：最后的“翻译官”
驱动层是操作系统和硬件之间的“翻译官”。它把块设备层的通用请求，翻译成硬件能理解的命令。
对于 HDD，驱动通过 ATA/SCSI 命令集跟硬盘通信。比如 READ SECTOR 命令，告诉硬盘读取某个扇区。对于 NVMe，驱动通过 PCIe 的 MMIO（内存映射 IO）提交命令到 Submission Queue，然后从 Completion Queue 取回结果。
我记得有一次做数据恢复，遇到一个 NVMe SSD 掉固件的情况。驱动层根本识别不到设备，因为 NVMe 的初始化流程需要固件响应。这种情况下，只能拆颗粒，用 Flash 读取器直接读 NAND 芯片。
驱动层交互的陷阱：
- NVMe 的 Namespace：一个 NVMe 设备可以有多个 Namespace，每个 Namespace 是一个独立的块设备
- HDD 的 4K 扇区：新硬盘用 4K 物理扇区，但模拟成 512 字节逻辑扇区，这叫 512e
- SSD 的 Write Amplification：SSD 写入前要先擦除，导致实际写入量大于请求写入量
在微内核架构中，驱动层运行在用户空间，通过 IPC 跟内核通信。这跟宏内核（Linux）不同，宏内核的驱动在内核空间。微内核的好处是驱动崩溃不会导致整个系统挂掉，但性能会差一些，因为 IPC 有开销。
我曾经在 seL4 微内核上移植过 NVMe 驱动。嗯，那真是个挑战。因为微内核的驱动不能直接访问硬件，要通过内核的 Capability 机制获取 IO 端口的访问权限。但好处是，驱动可以单独调试、单独重启，不会影响其他服务。
数据恢复中的驱动层技巧：
- 用
smartctl查看硬盘的 SMART 信息，判断硬件健康状态 - 用
nvme list查看 NVMe 设备信息 - 如果驱动层不识别设备，试试用
modprobe重新加载驱动模块 - 极端情况下，用
dd配合oflag=direct绕过驱动缓存
好了，这一章的内容就到这里。存储介质和接口是数据恢复的基础，理解这些底层原理，你才能在遇到问题时找到突破口。下一章我们会讲文件系统的数据结构，到时候你会看到，这些块设备的知识是怎么用上的。