上一篇我们讲过一种比较直观的 Dual-Port NVMe SSD（双端口SSD） 测试方法感兴趣的看这里：【高清视频】一块 SSD，两条 PCIe 链路：Dual-Port NVMe SSD测试环境怎么搭？（一）

一台普通 PC，加上一张 PCIe Gen5 Switch 卡，再从 MCIO 接口直接拉一根 MCIO x4 → U.2 2×2 Cable，就可以把 Dual-Port SSD 的两条 PCIe 链路跑起来。

这种方法有一个非常明显的优点：

简单、便宜、连接关系一眼就能看明白。

但如果测试对象从一块盘变成多块盘，或者希望更接近服务器、存储阵列里的实际使用环境，还需要做反复上电、掉电、Reset、Single Port/Dual Port 切换，甚至跑自动化测试，那么桌面上散着几块 SSD 和一堆电源线，就开始有点麻烦了。

所以这一次，我们换一种搭法。

在原来的：

PC + PCIe Gen5 Switch

基础上，再加入一台：

8 盘位 PCIe Gen5 JBOF(Just Bunch of Flash)盘柜。

这样整个测试环境就从“开放式实验平台”，进一步变成了一套更像数据中心存储系统的 Dual-Port SSD 验证环境。

为了方便工程师观看，我们针对本期视频并处理添加了中文字幕供大家参考。如果想看高清视频建议要在电脑上打开上面的视频链接进行观看！创作不易，欢迎分享到朋友圈或者与朋友讨论！如果想搬运我们的视频请告知我们。有时间的朋友直接观看下面的高清视频，没时间可以看下面的文字总结。

注意：本视频是以PCIe 5.0 8盘位盘柜为例介绍，实际上，PCIe 6.0 8盘位盘柜也有dual-port enable功能，参见下图user manual截图，可以支持测试E1, E3和U.2 SSD的dual port双端口功能。

一、为什么要加一个 JBOF 盘柜？

先看应用场景。

Dual-Port SSD 本身就是典型的企业级存储特性。

在银行、电信、电力、政务、社保、医疗以及大型数据中心的存储系统中，SSD 通常不会像普通 PC 里的 M.2 盘一样，只通过一条固定 PCIe 链路工作。

真正需要高可用的系统，更关心的是：

一条路径失效以后，另一条路径还能不能继续访问？

一个 Controller 出现问题以后，盘还能不能被另一条路径接管？

SSD 掉电、重新上电、Reset 以后，Host 能不能正确重新枚举？

所以 Dual Port 真正重要的地方并不只是“有两条 PCIe Lane 组合”，而是：

为高可用、多路径和故障切换提供硬件基础。

这一次使用的 Serial Cables PCIe Gen5 8-bay Passive JBOF，官方型号为 PCI5-ENC8-E3-08，提供 8 个盘位，并支持 E3、U.2/U.3 以及通过转接板安装 M.2，同时支持 Single-Port 1×4 和 Dual-Port 2×2 模式。官方配置中还带有 500W 电源。

因此，这套盘柜并不只是一个“把 SSD 装进去的铁盒子”。

它真正有价值的地方在于：

连接、供电、Sideband、Dual-Port 模式以及每个 Slot 的管理，都可以统一起来。

二、从 PC 开始：CPU 旁边插一张 Gen5 Switch 卡

整个环境仍然从一台普通 PC 开始。

在 CPU 附近的 PCIe 插槽中，我们安装的是 Serial Cables PCIe Gen5 Switch Host Card。

这张卡的角色可以简单理解为：

把主机 CPU 的一条上行 PCIe 链路，扩展成多条可以接 SSD、盘柜或者其他 PCIe 设备的下行链路。

卡的上方还有 PCIe 插槽，可以用于 GPU、显卡或者一些 SSD 验证卡。

而在卡的侧面，则提供了 MCIO 接口。

前一次演示中，我们直接从其中一个 MCIO 接口拉出一根线：

MCIO → U.2

然后直接连接一块 Dual-Port SSD。

这一次连接方式不同：

MCIO 不再直接接盘，而是先接 JBOF 盘柜。

所以拓扑变成了：

CPU
 │
PCIe
 │
Gen5 Switch Host Card
 │
MCIO Gen5
 │
JBOF盘柜
 │
背板 / Drive Tray
 │
Dual-Port NVMe SSD

从结构上看，它已经明显更接近服务器和企业级存储系统。

三、Switch 卡到盘柜：一根 Gen5 MCIO x4 线

这次从 Switch 卡的 MCIO 接口出来，我们使用一根：

PCIe Gen5 MCIO x4 → MCIO x4

线缆。

演示中的线长约：

0.5 米。

也就是说，这次不再像上一篇那样：

MCIO
 ↓
U.2
 ↓
SSD

而是：

MCIO
 ↓
MCIO
 ↓
JBOF

数据先送到盘柜，再由盘柜内部背板送到具体 SSD Slot。

这一点看起来只是“中间多了一个盒子”，实际意义却很大。

因为从这里开始：

SSD 供电、Presence Detect、Reset、Dual-Port 模式以及 Sideband 信号，都可以由盘柜统一管理。

四、看看盘柜后面：8 个 MCIO 口，对应 8 个盘位

把盘柜转到背面以后，结构就很直观了。

首先有 AC 电源输入。

然后是管理接口，包括：

Ethernet 网络接口

以及：

USB Type-C 管理接口。

演示中使用的是 USB Type-C 连接旁边的一台调试电脑，然后通过 Tera Term 进入盘柜的 CLI。

Serial Cables 官方手册也给出了这一管理方式。例如 USB 串口模式下，可以使用 Tera Term，典型串口设置为：

115200 baud、8 data bits、No parity、1 stop bit、No flow control。

后面最重要的则是：

8 个 MCIO 接口。

这 8 个接口和前面的 8 个 SSD Slot 形成对应关系。

可以简单理解成：

Rear MCIO 1 → Slot 1
Rear MCIO 2 → Slot 2
Rear MCIO 3 → Slot 3
……
Rear MCIO 8 → Slot 8

这次为了演示，只连接其中一路。

如果以后要把 8 个 Slot 都接起来，就需要把对应的数据链路全部连接完成。

五、前面是 8 个独立盘位

再转到盘柜前面。

从左到右或者从下到上，根据盘柜摆放方向，可以看到：

Slot 1～Slot 8。

盘柜可以横着摆，也可以竖着摆。

这次我们把测试盘安装在：

Slot 5。

为了让大家看清楚内部结构，演示中特意拆掉了其中一个 Drive Tray。

把 Tray 抽出来以后，就能看到这个盘柜设计里一个非常重要的特点：

它采用 EDSFF 接口体系。

Serial Cables 官方说明中，这款 Gen5 JBOF 可以直接支持 E3.S、E3.L 等 EDSFF 设备，也可以通过 Interposer/Adapter 使用 U.2、U.3 以及 M.2 SSD。官方手册在 showslot 部分也明确列出了 E3-to-U.2、E3-to-U.3 和 E3-to-M.2 Interposer。

六、为什么盘柜采用 EDSFF 接口，而不是只做 U.2？

这是一个值得多说几句的地方。

很多做 SSD 的人会觉得：

企业级盘柜，直接做成 U.2/U.3 不就行了吗？

但 EDSFF 的优势在于，它并不只面向 SSD。

E3 家族的 Edge Connector 本身可以支持比普通 x4 SSD 更宽的 PCIe 接口。

SNIA 对 EDSFF E3 的说明中明确指出，E3 能够支持：

PCIe x4、x8 甚至 x16。

而且除了 SSD，也可以承载其他 PCIe 设备。

这件事到了 CXL 时代就更有意义。

例如 Micron 的 CZ120 CXL 2.0 Type-3 Memory Expansion Module 采用的就是：

E3.S 2T + PCIe Gen5 x8。

所以视频里提到：

为什么内部要考虑 x8 能力？因为未来不仅是 SSD，还可能连接 CXL Memory Module。

这个方向是成立的。

不过这里也需要区分两个概念：

EDSFF 连接器“可以支持 x8”

和

当前这个 Slot 实际跑 x8

不是一回事。

对于今天这个 Dual-Port SSD 演示，我们真正使用的数据通道仍然是：

x4 总带宽。

只是这 4 条 Lane 进一步组织成：

x2 + x2。

也就是说：

E3/EDSFF Physical Interface
        │
       x4
   ┌────┴────┐
   │         │
Port A x2  Port B x2

七、但今天测的是 U.2 Dual-Port 盘，怎么办？

问题来了。

盘柜里面默认面向 EDSFF，而我们手里的测试盘却是：

U.2 Dual-Port NVMe SSD。

怎么办？

很简单：

加一块 Adapter。

演示中使用的是：

U.2 → EDSFF Adapter / Interposer。

先把 U.2 SSD 固定在转接板上，再把转接板固定到 Drive Tray 里。

然后：

整个 Drive Tray 插入盘柜。

这样原本的 U.2 SSD，从盘柜角度看，就可以通过 EDSFF 背板接入整个测试系统。

如果测试对象本来就是 E3.S SSD，则更简单：

不需要 U.2 转接板，直接把 E3.S 固定在 Tray 上插进去即可。

这也是这种 JBOF 架构比较方便的地方。

同一个测试平台，不必为了：

U.2、

U.3、

E3.S、

M.2

分别准备四套完全不同的测试机。

八、上电以后，第一件事不是跑性能，而是看“两条路”有没有起来

物理连接完成以后启动 PC 和 JBOF。

接下来先到 Linux 主机端确认设备枚举。

演示中首先执行：

nvme list

可以看到两个外观上几乎相同的 NVMe 条目。

然后再执行：

lspci

能够看到两条对应的 PCIe 设备路径，演示中的 BDF 位置分别出现在类似：

11

和

13

的位置。

这里特别容易产生一个误解：

“是不是插了一块 SSD，Linux 却发现了两块 SSD？”

不是。

这是 Dual-Port 环境里一个非常典型的现象。

一块物理 Dual-Port NVMe SSD 可以通过两个 PCIe Port 提供两条访问路径，所以 Host 侧可能看到两个 NVMe Controller/Path。

真正要确认的是：

Serial Number 是不是对应同一块物理设备？

Namespace 是不是同一个存储空间？

两个 PCIe Controller 是不是分别来自两条路径？

而不是简单看 nvme list 里有几个名字。

Linux 原生 NVMe Multipath 还可以把具有相同标识的 Namespace 路径整合成一个逻辑 Block Device，然后根据 NUMA、Round-Robin 或 Queue Depth 等策略选择具体路径，所以不同 Linux Kernel 和 Multipath 配置下，最终显示形式可能并不完全一样。

因此，在 Dual-Port 验证中，我建议至少分三层看：

PCIe 层

lspci

看两条 PCIe Link。

NVMe Controller 层

查看两个 Controller 是否存在。

Namespace / Multipath 层

确认最终是不是指向同一个逻辑存储设备。

这三层不要混为一谈。

九、再看盘柜自己有没有认到这块盘

Host 端看完以后，再回到 JBOF 管理端。

通过 Tera Term 进入 CLI 以后，可以输入：

showslot

这时能够看到各个 Slot 的 Presence 状态。

演示中 Slot 5 显示：

Yes

说明 JBOF 已经检测到：

第五号盘位里面确实插入了设备。

这一点也和官方手册相符，showslot 就是用于显示 Slot 信息以及 SSD Presence Detection。

需要注意：

这里的“有盘”主要说明 Presence 已经检测到。

它和：

实际协商到 Gen3、Gen4 还是 Gen5

是两个概念。

因为本次演示使用的 Intel Dual-Port SSD 本身属于较早期的 Gen3 设备，即使前面的 Switch、Cable 和 JBOF 都支持 Gen5，最终 SSD 链路速度仍然受 Endpoint 自身能力限制。

十、最关键的一条命令：dual 5 on

接下来就是整个 Dual-Port 盘柜测试里最关键的一步。

JBOF 默认 Slot 配置为 Single-Port。

也就是说，一般情况下一个 Slot 会按：

PCIe x4

去使用。

如果现在插入的是 Dual-Port SSD，希望把这 4 条 Lane 拆成：

x2 + x2

就需要把这个 Slot 切换到 Dual Channel 模式。

演示中 Slot 5 使用的命令是：

dual 5 on

意思就是：

打开 Slot 5 的 Dual Channel 模式。

Serial Cables 官方手册对这个命令的定义也很清楚：

dual <slot> <on/off>

例如：

dual 1 on
dual all on

用于打开指定 Slot 或者全部 Slot 的 Dual Channel。

这里有一个技术细节最好讲清楚：

dual 5 on 并不是把一块普通 Single-Port SSD“变成”Dual-Port SSD。

它做的是：

把盘柜 Slot 的链路组织方式配置成 Dual Channel。

真正的 SSD 本身必须支持 Dual Port。

否则盘柜即使切换成 2×2，也不可能凭软件创造出 SSD 内部不存在的第二个 PCIe Port。

十一、Single Port 和 Dual Port，本质差在哪里？

把这 4 条 PCIe Lane 画出来就很好理解。

Single Port 模式：

Lane 0
Lane 1
Lane 2  ─────→ 一个PCIe x4 Port
Lane 3

Dual Port 模式：

Lane 0
Lane 1  ─────→ Port A：PCIe x2

Lane 2
Lane 3  ─────→ Port B：PCIe x2

所以总 Lane 数量并没有变。

仍然是：

4 条。

变化的是：

原来一个 x4 Link，现在变成两个独立 x2 Link。

如果是 Gen5 Dual-Port SSD，理论上可以表现为：

Gen5 x2 + Gen5 x2。

而今天使用的是较早的 Intel Gen3 Dual-Port SSD，因此最终只能按照 SSD 支持的代际建立链路。

视频中还提到，一些企业级 SSD 可以根据平台配置适配 Single-Port 和 Dual-Port 工作方式；具体到某一个三星、铠侠或者其他型号，仍应以对应 SSD Datasheet 和 Firmware 能力为准，不能笼统认为所有企业盘都支持这种切换。

十二、盘柜 CLI 能做的事情，比“认盘”多得多

如果这个盘柜只能用来装 8 块盘，那么价值其实有限。

真正有意思的是它的管理能力。

官方 Gen5 JBOF 手册列出了相当完整的一组 MCU CLI 命令。

其中比较值得做 SSD 验证的几个功能包括：

1. syspwr

整个 JBOF：

Power On / Power Off。

2. ssdpwr

对单独某个 Slot 进行：

SSD Power On / Off。

例如：

ssdpwr 5 off

然后再：

ssdpwr 5 on

这和手工拔电源线不是一回事。

它特别适合做：

反复掉电/上电测试。

3. ssdrst

对指定 SSD 执行 Reset。

在验证：

PCIe Reset

设备恢复

重新枚举

等问题时非常有用。

4. showslot

检查：

哪个 Slot 插了盘。

5. dual

设置：

Single / Dual Channel。

这是今天这个 Dual-Port 环境最核心的命令之一。

6. pwrdis

控制 EDSFF 相关的：

PWRDIS。

官方手册明确支持按 Slot 控制 PWRDIS 的 High/Low 状态。

7. hled

控制 Drive 上的 Host LED。

8. buz

控制盘柜蜂鸣器。

9. iicwr / iicw

访问：

I²C Sideband。

可以针对具体 Slot 进行 I²C 读写。

10. ver / sysinfo

查看：

Firmware 版本

以及：

系统信息、温度、风扇、电源状态等。

所以从验证工程师角度看，这台 JBOF 并不只是一个“8 盘盒”。

它其实还是一个：

能够被程序控制的 SSD 测试基础设施。

十三、为什么它特别适合做自动化？

这也是我认为盘柜方案比裸线方案最大的优势之一。

现在 Host 上本来就在跑 Linux。

而盘柜又可以通过：

USB

或者：

Ethernet

接受管理命令。

那么就可以把两边组合起来。

例如 Python 脚本首先给 JBOF 发命令：

dual 5 on

然后：

ssdpwr 5 off

等待若干秒后：

ssdpwr 5 on

接着 Linux 端检查：

lspci
nvme list

确认两条 Path 是否重新出现。

然后继续跑：

fio

或者：

nvme-cli

执行读写和 NVMe Admin/I/O Command 测试。

于是整个测试过程就可以变成：

配置Slot
   ↓
SSD上电
   ↓
等待Link Up
   ↓
检查PCIe枚举
   ↓
检查NVMe枚举
   ↓
运行fio
   ↓
SSD掉电
   ↓
重新上电
   ↓
再次检查
   ↓
记录Pass / Fail
   ↓
循环100次、1000次……

这时候，原本工程师需要不停：

拔线、插线、按按钮、看屏幕

的工作，就有机会变成自动化 Regression Test。

十四、这对于 Dual-Port 验证尤其有意义

例如可以进一步设计这种测试：

正常情况下：

Port A：Up
Port B：Up

开始持续 I/O。

然后模拟其中一侧异常：

Port A：异常/Reset
Port B：保持工作

观察：

Host 有没有正确处理 Path 变化？

NVMe Multipath 是否切到另一条路径？

I/O 有没有异常中断？

然后再恢复 Port A，观察系统是否重新发现和恢复这条路径。

Linux 原生 NVMe Multipath 本身就支持多路径选择和 Failover，并可采用 NUMA、Round-Robin 以及 Queue-Depth 等策略。

所以：

Dual Port 的价值不是“Linux 能看到两个设备”就结束了。

真正值得测试的是：

其中一条路坏掉以后会发生什么。

十五、盘柜方案和前一篇的“直接拉线方案”，到底该怎么选？

到这里，两种 Dual-Port 环境其实已经很清楚了。

第一种：Switch + MCIO 转 U.2 Cable

结构：

PC
 ↓
Gen5 Switch
 ↓
MCIO → U.2 2×2 Cable
 ↓
Dual-Port SSD

优点：

结构简单

成本低

链路关系非常直观

非常适合单盘调试

缺点：

供电需要另外解决

桌面线缆比较杂

多盘扩展不够整洁

自动化掉电和 Slot 管理不够方便

第二种：Switch + JBOF

结构：

PC
 ↓
Gen5 Switch
 ↓
MCIO
 ↓
8-Bay JBOF
 ↓
Dual-Port SSD

优点：

盘柜统一供电

Slot 独立管理

支持 Single/Dual Channel 切换

支持 SSD Power On/Off

支持 Reset

支持 I²C Sideband

可以通过 USB/Ethernet 自动化

同时可以管理多块盘

环境更加整洁

缺点也很现实：

成本更高。

除了 PC 和 Switch Card，还需要：

JBOF

MCIO Cable

以及针对不同 Form Factor 使用的：

Adapter / Interposer。

所以如果只是临时验证一块 Dual-Port SSD：

第一种方案更经济。

如果要长期做：

多盘验证、Firmware Regression、Power Cycle、Reset、Dual-Port 切换以及自动化测试

那么第二种盘柜方案明显更加合适。

十六、还有一点：Gen5 盘柜和 Gen6 盘柜的思路正在继续往前走

这次演示的是 Gen5 JBOF。

Serial Cables 目前也已经有 Gen6 版本的 8 盘位 HYDRA JBOF。

Gen6 HYDRA 仍然采用 8 个 EDSFF 盘位，但已经进一步加入每 Slot 独立 Power Control、Reset、Link 状态、温度/电压/电流监控，以及 Python API 等自动化能力，并支持 PCIe、NVMe 和 CXL 验证。

这其实能够看出一个很明显的趋势：

以前的盘柜只是：

“把很多 SSD 装进去。”

现在的验证型 JBOF 正在变成：

“可以被程序控制的 PCIe/NVMe/CXL 测试平台。”

尤其到了 Gen6 和 CXL 时代，单纯“盘能不能认出来”已经远远不够。

工程师真正需要的是：

Link 状态

Sideband

Power

Reset

Hot-Plug

Fault Injection

以及：

自动化 API

一起工作。

十七、最后把整个搭建过程压缩成一条线

如果把今天将近 9 分钟的演示浓缩成一个流程，其实就是：

第一步

PC 的 CPU 附近 PCIe 插槽安装：

Serial Cables PCIe Gen5 Switch Host Card。

第二步

从 Switch Card 的 MCIO 口拉出：

Gen5 MCIO x4 → MCIO x4 Cable。

第三步

连接：

Serial Cables PCIe Gen5 8-bay JBOF。

第四步

如果测试 E3 SSD：

直接安装到 Drive Tray。

如果测试 U.2 Dual-Port SSD：

使用：

U.2 → EDSFF Adapter

再装入 Drive Tray。

第五步

把 Drive Tray 插入指定 Slot。

本次演示：

Slot 5。

第六步

通过 USB Type-C 或者 Ethernet 进入 JBOF CLI。

确认：

showslot

能够识别 Slot 5 的设备。

第七步

针对 Dual-Port SSD 执行：

dual 5 on

让这个 Slot 工作在 Dual Channel 模式。

第八步

Linux Host 执行：

lspci

确认两条 PCIe 路径。

再通过：

nvme list

以及进一步的 NVMe 信息确认 Controller 和 Namespace 状态。

第九步

开始：

fio / nvme-cli

测试。

第十步

配合：

ssdpwr
ssdrst
dual
pwrdis

做 Power Cycle、Reset、Single/Dual Port 切换以及后续自动化测试。

到这一步，一套相对完整的 Dual-Port SSD 盘柜测试环境就基本搭好了。

结语：Dual-Port 真正要测的，不是“看到两个盘”

如果只看表面，Dual-Port 测试好像很简单：

插一块盘，Linux 看到两个 NVMe 设备，就结束了。

实际上远远不够。

真正的 Dual-Port 验证，应该从：

物理链路

一路看到：

PCIe 枚举

再到：

NVMe Controller / Namespace

再到：

Multipath

最后再通过：

Power Cycle、Reset、Path Failure 和持续 I/O

去验证整个系统发生异常以后，到底能不能恢复。

第一种“Switch + Cable”方案，适合快速把环境跑通。

而今天这套：

Gen5 Switch + 8 盘位 JBOF

则进一步把供电、Sideband、Dual-Port 模式和自动化控制统一到一个测试平台里面。

如果后面需要做的已经不是“一块盘能不能 Link”，而是几十轮、几百轮甚至几千轮的 Regression Test，那么盘柜方案的价值就会越来越明显。

这也是企业级 SSD 测试和普通消费级 SSD 测试之间，一个非常典型的区别：

我们真正关心的，往往不是它正常的时候有多快，而是当链路、供电或者系统出现异常以后，它还能不能正确地回来。

免费下载Saniffer公司白皮书

希望获得更多关于PCIe5.0&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试技术和产品，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。

欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。