数据中心正经历一场由 AI 大模型和海量数据分析驱动的内存革命。随着 CPU 核心数呈指数级增长传统服务器架构正面临严重的“内存墙”Memory Wall与“内存闲置”Stranded Memory难题。Comput Express Link (CXL)技术的诞生彻底打破了节点间内存隔离的藩篱。而为了让上层应用无需重写就能吞吐几百 TB 的共享内存专门为织网附加内存打造的famfs (Fabric-Attached Memory Filesystem)文件系统应运而生。本文将深入解析 CXL 的技术演进与架构并结合 Linux 内核顶级峰会LSFMMBPF的最新动态还原 famfs 的设计精髓及其合入内核的前沿历程。第一部分CXL 架构解析——从历史演进到技术细节1. 诞生背景与历史演进在 CXL 出现之前服务器的内存扩展严重受限于 CPU 的内存通道数和物理管脚。虽然各大巨头提出了 CCIX、Gen-Z、OpenCAPI 等标准但最终 CXL 凭借 PCIe 物理层的生态优势脱颖而出。CXL 1.0 / 1.1 (2019):基于 PCIe 5.0实现 CPU 与单机内加速器GPU/FPGA之间的内存扩展与低延迟缓存一致性。CXL 2.0 (2020):引入 CXL Switch交换机与 DCD动态容量分配使得内存池化Memory Pooling成为可能多台服务器可以按需划分内存。CXL 3.0 / 3.1 (2022-2023):升级至 PCIe 6.0引入 Fabric织网拓扑与多级交换实现多节点间的点对点共享内存Shared Memory。2. CXL 的协议与设备分类CXL 运行在 PCIe 物理层之上由三大子协议驱动CXL.io类似于标准 PCIe负责设备发现、配置和 DMA。CXL.cache允许外部设备如 GPU直接访问和缓存 CPU 的主机内存。CXL.mem允许 CPU 将外部设备如 CXL 内存扩展卡映射到全局物理地址空间中当作本地内存直接访问。在三种设备类型Type 1/2/3中Type 3内存扩展与池化设备是目前数据中心应用最广泛的形态也是famfs的底层支撑核心。第二部分famfs 如何在 CXL 上工作famfsFabric-Attached Memory Filesystem由美光Micron工程师 John Groves 领导开发是专门针对 CXL 等共享内存设备设计的高性能专用文件系统。----------------------------------------------------------------------------------- | 应用层 (Analytics / Big Data / AI) | ----------------------------------------------------------------------------------- | mmap() / memcpy() 直接物理访存 (绕过 POSIX API) | ----------------------------------------------------------------------------------- | famfs 文件系统 (管理元数据与映射) | ----------------------------------------------------------------------------------- | Linux DAX 驱动 (Direct Access) | ----------------------------------------------------------------------------------- | CXL.mem 协议 (将 CXL 共享内存映射到 CPU 物理地址空间) | ----------------------------------------------------------------------------------- | CXL Type 3 设备 / CXL Switch 共享内存池 (100TB 共享 Memory Fabric) | -----------------------------------------------------------------------------------核心工作逻辑共享 DAX 设备映射CXL 通过CXL.mem将共享内存映射到各服务器 CPU 的全局物理地址空间。famfs基于 Linux 的DAXDirect Access机制将物理内存直接暴露给用户态。主从节点架构Master / ClientMaster Node主节点负责创建预分配文件并管理元数据。主节点先将数据从传统文件系统如 XFS写入 CXL 内存。Client Nodes客户端节点挂载同一个famfs卷直接读取元数据布局。数据交错Interleaving为提高吞吐量数据通常会在多个 CXL 设备间交错分布。famfs通过内部的File Map文件映射记录逻辑偏移与多个 DAX 设备的物理映射。零拷贝物理访存mmapmemcpy应用通过famfs调用mmap()映射内存后续读取完全抛弃传统系统调用直接通过memcpy()或 CPU 加载指令直接对内存进行读取。第三部分内核拉锯战——LSFMMBPF 2026 现场实录与突破尽管 CXL 硬件蓬勃发展但famfs进入 Linux 主线内核的道路却充满了曲折。在LSFMMBPF 2026 Summit上John Groves 与内核社区展开了一场关于合并famfs的深度辩论。1. 提案背景与矛盾焦点John Groves 在会议开始时直言famfs 自 2023 年以来一直在“让 VFS 和 FUSE 的日子变得更难过”但文件系统社区也一直在“要求过于完美以至于阻碍了良好方案的落地”。Groves 再次强调“famfs 不能用作通用文件系统”。它服务于非稀疏、可共享的内存文件主要用于只读或高并发数据分析。由于硬件上已经出现了 100TB 级别的内存设备应用急需这种抽象接口而无需重写底层代码。目前 famfs 维护着两个版本独立内核模块版和基于 FUSE 的版本。但后者需要对 FUSE ABI 进行修改且性能不如独立版本因此陷入了合并困境。2. 方案大碰撞BPF vs. iomap在辩论过程中社区就如何处理文件映射展开了激烈讨论BPF 方案的兴起与破灭此前有人建议使用 BPF 程序作为缺页异常处理程序Fault Handler来动态计算交错区段。Groves 尝试了 Gregory Price 在 LLM 协助下编写的 BPF PoC 验证但未能成功运行。开发者们一致认为famfs 是性能敏感型组件引入 BPF 极其复杂且“糟糕透顶”。Christoph Hellwig 的通用化诉求内核资深开发者 Christoph Hellwig 反对为 famfs 单独修改 FUSE 机制。他指出应该借由 Darrick Wong 正在做的 FUSEiomap工作构建通用的条带化Striping映射层供更多文件系统如 Btrfs共同使用。映射膨胀问题与妥协Darrick Wong 随后指出如果用常规iomap处理一个 100TB、按 2MB 切片的巨型文件内核将不得不存储数百亿条物理 Extent 记录造成内核内存爆表。而 famfs 采用三参数数学公式描述条带模式开销极小。3. 破局与前行之路Hellwig 坦言条带化的描述公式早已成熟只需 3 个参数完全不需要自定义可执行代码如 BPF。Groves 也承认这正是他协议补丁中所采用的结构。最终现场达成了宝贵的共识统一接口FUSE MapDarrick Wong 建议接手 Groves 的文件映射补丁将其重命名为通用的FUSE map合并入他正在推进的 FUSEiomap主线框架中。协议通用化FUSE 维护者 Miklos Szeredi 和 Amir Goldstein 表示只要消息结构保持通用允许其他分布式/条带化场景使用即可将该扩展合并进 FUSE 协议。这场长达数年的探讨终于在 LSFMMBPF 2026 上迎来了曙光为 famfs 最终合入 Linux 内核主线奠定了坚实的基础。