news 2026/7/30 20:27:37

【高清视频】面向 PCIe Gen6 及下一代数据中心的 SSD 形态演进

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
【高清视频】面向 PCIe Gen6 及下一代数据中心的 SSD 形态演进

昨天看到一篇介绍未来PCIe SSD接口的文章,《这就是存储的未来:EDSFF技术分析》,介绍了为什么PCIe 6.0在SSD接口上全面转向了EDSFF,并配了详细的解说和高清视频。其实,PCI SIG在2024年3-4月份的时候已经决定未来PCIe 6.0 SSD仅保留EDSFF接口,例如E3, E1等,但是大概一年后的2025年中,有些最终用户可能还希望保留U.2, M.2等接口一段时间,但是这个也仅能是延缓U.2, M.2接口一些时日而已,目前支持U.2, M.2的connector都还在等待过程中。

我们今天下面的文章综合了上面文章的主要内容,对于想了解为什么未来SSD会转向EDSFF的朋友提供一个快速参考。

以下视频来源于Bilibili博主HOMOLAB

【高清视频】面向 PCIe Gen6 及下一代数据中心的 SSD 形态演进

一、引言:为什么需要 EDSFF?

EDSFF(Enterprise & Datacenter SSD Form Factor --> EDSFF 这个单词的缩写已经前几年从早期的Enterprise and Data Center SSD Form Factor更名为Enterprise and Data Center Standard Form Factor,感兴趣的可以看saniffer公众号之前的文章:EDSFF 缩写更名背后的故事)并不是一次简单的接口升级,而是在 PCIe Gen6 及之后时代,对企业级 SSD 在容量、性能、电气、散热和系统集成方面进行的系统性重构

传统2.5 英寸 U.2 SSD的物理尺寸和电气设计,源自机械硬盘时代的历史包袱,在当下已经难以支撑:

  • 更高通道数的 NVMe 主控

  • 更高的链路速率(PCIe Gen5/Gen6)

  • 更高功耗(20–25W 乃至更高)

  • 更高密度(TLC / QLC / 未来 PLC)

EDSFF 正是在这一背景下,被业界视为U.2 与 M.2 的下一代替代方案


二、历史背景:从 HDD → SATA SSD → NVMe U.2 的路径依赖

1. 2.5 英寸规格的历史成因

  • 1956 年 IBM 发明机械硬盘,奠定了 HDD 的物理尺寸体系

  • 随后形成 1.8 / 2.5 / 3.5 英寸等规格

  • 早期 SATA SSD 为了兼容生态,沿用了 2.5 英寸 HDD 规格

2. NVMe 时代的结构性矛盾

随着 NVMe 与多通道主控出现:

  • 7.5mm 厚度无法容纳:

    • 双层 PCB

    • 大容量电容(PLP)

    • 高功耗主控散热

  • 企业级 SSD 功耗从 ~5W 上升到 15–25W

3. U.2 的阶段性解决方案

  • 2014 年左右,企业级 SSD 转向15mm U.2

  • 使用SF8639连接器

  • 维持了约 6 年的“相对稳定期”

但 U.2 的根本问题并未解决。


三、U.2 的核心瓶颈(为何“已经力不从心”)

1. 连接器与电气性能

  • SF8639 源自 SATA / SAS 时代

  • 体积大、插损高、串扰严重

  • 难以支撑 PCIe Gen6 及以上的信号完整性要求

2. 结构与容量矛盾

  • 要么使用刚柔板折叠(增加成本、降低可靠性)

  • 要么浪费空间(限制最大 NAND 密度)

  • 不利于 QLC 超大容量,也限制 TLC 的空间利用率

3. 散热设计先天不足

  • 2.5 英寸外形未为 20W+ SSD 设计

  • PCB 位于中间,限制散热鳍片与热交换面积

  • 单位气流下散热效率低

结论是:

U.2 要小不够小,要大不够大,既无法极致 mini,也无法极致 scale。


四、EDSFF 的诞生:从 Intel “Ruler” 到行业共识

1. Ruler 的起点

  • 2017 年:Intel 推出Ruler(尺子)规格,容量直接拉到 8TB

  • 2019 年:P4326 达到30.72TB

2. EDSFF 的正式形成

  • Intel 将 Ruler 与 Gen-Z 连接器整合

  • 形成EDSFF(Enterprise & Datacenter SSD Form Factor)

EDSFF 的核心定位:

  • 为 SSD 而生

  • 面向企业级与数据中心

  • 从设计之初即考虑高功耗、高速率、高密度


五、EDSFF 的规格体系:E1 / E3 + 长度 + 厚度

1. 横向宽度

  • E1:窄型(“竹竿”)

  • E3:宽型(“胖子”)

2. 长度

  • Short(S)

  • Long(L),例如E1.L 长度可达 318.75mm

3. 厚度(高度)

  • 1T / 9.5mm / 15mm / 2T 等

  • 厚度越大,散热潜力越强

4. 连接器与兼容性

  • 统一使用Gen-Z 风格连接器

  • 通过接口对齐实现系统级兼容


六、电气层面的决定性优势(EDSFF 的“胜负手”)

1. PCIe Gen5 / Gen6 的挑战

  • Gen5:全链路插损 ≤ 36dB

  • Gen6:插损目标进一步降至 ~32dB

  • PAM4 带来:

    • 更窄的眼图

    • 更高 BER

    • 更低噪声容忍度

2. U.2 拓扑的先天劣势

CPU → PCIe Slot → 转接卡 PCB → SF8639 母座 → SF8639 子座 → SSD

  • 多一次连接器 ≈ +1dB 插损

  • FR4 上每 2.5cm ≈ +2dB

系统裕量被迅速吃光。

3. EDSFF 的结构性改进

  • 使用Gen-Z 连接器

  • 子端由 PCB 直接延伸,无需额外座子

  • 减少一个连接器 = ~1–1.25dB 插损回收

  • RX / TX 不再交错,大幅降低串扰

结论:

在 Gen6 / Gen7 时代,EDSFF 是唯一现实可行的 SSD 形态。


七、形态灵活性:能屈能伸,覆盖多种应用

1. 小体积(Boot / Cache)

  • E1.S 5mm

  • 类似 M.2,但面积更大

  • 可实现 PLP + 热插拔

2. 极致容量

  • E1.L / E3.L

  • 可达 122TB 甚至 256TB

  • 无需刚柔板,降低 BOM 与布线复杂度

3. 中庸之选(主流)

  • E1.S 15mm / E3.S 1T

  • 在性能、密度、散热之间取得平衡

  • 当前最受厂商青睐


八、线缆、背板与转接:系统集成的新问题

1. 服务器主流方案

  • MCIO → EDSFF 线缆

  • 直连方式减少 PCB 插损

2. 混合正交背板(SNIA / Molex)

  • 信号走线缆

  • 背板只负责供电

  • 降低成本与信号风险

3. 风险与警示

  • Gen-Z 连接器无防呆

  • 反插 =100% 损坏 SSD

  • DIY 场景风险极高


九、未来展望与挑战

1. 技术问题而非设计缺陷

  • 厚度选择(9 / 15 / 25mm)

  • 超长 E1.L 的 SI 约束

  • 与 CXL.Memory / Gen-Z 4C 的协同

2. 行业趋势

  • OEM 已明确放弃 Gen6 U.2

  • 主流厂商全面转向 EDSFF

  • Gen6 时代将加速完成替换


十、总结:EDSFF 为何是“不可逆的未来”

EDSFF 以更优的电气性能、更强的散热能力、更高的存储密度,以及高度可定义的形态,彻底摆脱了 U.2 的历史包袱。

在 PCIe Gen6 及之后的时代:

  • U.2 没有船票

  • EDSFF 是唯一方向

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/7/31 5:44:32

Spring MVC与Spring Security中CORS配置的那些坑,你踩过几个?

第一章:Java解决跨域问题CORS配置 在前后端分离的开发架构中,浏览器出于安全考虑实施同源策略,导致前端应用无法直接请求不同源的后端接口。跨域资源共享(CORS)是一种W3C标准,允许服务器声明哪些外部源可以…

作者头像 李华
网站建设 2026/7/31 5:44:34

百万级Excel导出不OOM、不超时、不阻塞主线程——阿里系高并发导出架构设计(含完整Spring Boot响应式实现)

第一章:百万级Excel导出的核心挑战与架构目标 在企业级应用中,面对百万级数据量的Excel导出需求,传统同步导出方式极易引发内存溢出、响应超时和系统阻塞等问题。如何在保障系统稳定性的前提下高效完成大数据量导出,成为后端架构设…

作者头像 李华
网站建设 2026/7/28 10:29:15

理解 envFrom.secretRef 应用

一、核心含义:一句话理解 envFrom.secretRef envFrom: - secretRef: {name: my-secret} 的本质是: 把 K8s 中名为 my-secret 的 Secret 资源里的所有「键值对」,自动转换成容器内的「环境变量」,应用代码可以直接通过读取环境变量…

作者头像 李华
网站建设 2026/7/31 5:44:32

Java Debug效率革命?飞算JavaAI一键修复器全面评测

Java开发过程中,Bug排查始终是影响开发效率的核心痛点。无论是新手面对控制台冗长报错日志的手足无措,还是资深开发者花费数小时排查隐藏的逻辑漏洞、依赖冲突,甚至是简单的语法疏漏,都在无形中消耗着开发人员的时间与精力。为验证…

作者头像 李华
网站建设 2026/7/31 5:44:33

7.3 实战演练:监听镜像变更与监听应用定义的双模式工作流打造

7.3 实战演练:监听镜像变更与监听应用定义的双模式工作流打造 1. 引言:两种 GitOps 模式之争 在 GitOps 实践中,有两种主流模式: 监听应用定义(App-of-Apps):Argo CD 监听 Git 中的应用定义变更,自动同步。 监听镜像变更(Image-based):Argo CD Image Updater 监听…

作者头像 李华
网站建设 2026/7/30 16:27:29

【Java单例模式终极指南】:20年架构师亲授7种实现方式的性能、线程安全与反序列化陷阱全解析

第一章:单例模式的核心原理与应用场景 单例模式是一种创建型设计模式,确保一个类在整个程序生命周期中仅存在唯一实例,并提供全局访问点。其核心在于控制实例化过程——通过私有化构造函数、静态私有实例变量以及公有静态获取方法三者协同实现…

作者头像 李华