本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
前段时间，华为搞了一个 Peerium 架构，号称是突破了冯诺依曼单机架构。能让百万级处理器作为一台计算机协同工作，并称其“突破了图灵范式，提出了 Nested BSP，颠覆了长久以来的主从架构”。
看到这个消息，不少人或“踩”或酸，说啥的都有。而最近的 Linux 管道技术大会（LPC 2026）上，华为工程师正式展示了一款名为 XMFS 的实验性文件系统。应该说就是这个 Peerium 架构的延伸，在文件系统处理上，相比 tmpfs 从 3.25 秒到 1.99 秒快了不少，性能超越并秒杀了 tmpfs。
这次华为低调出手，与只差一个字母的 XFS、容器冷启动提速 40%、内存池化的文件系统有何亮点？为啥能引起大量老外关注，我们就一起来看看这个 XMFS 有何魅力吧！
文件系统发展史
计算机架构的演化，离不开文件系统的支持。而文件系统的发展始终又与硬件演进和应用需求紧密相连。
总结来看，大概有下面 5 个阶段。
- 早期单机集中式阶段（1960s – 1980s）。文件系统架构的初始形态是以单机文件系统为代表的集中式存储模式。这一时期的代表如 FAT 和早期 Unix FFS，主要解决本地磁盘的基本目录管理和数据存取问题，但受限于单节点的容量和性能。
- 网络文件系统阶段（1980s – 1990s）。随着以太网技术的蓬勃发展，研究重点转向实现网络环境下的资源共享。NFS（Network File System）和 SMB/CIFS 等协议应运而生，允许客户端通过网络透明地访问远程文件，但其性能仍高度依赖中心服务器。
- 日志型与高性能单机阶段（1990s – 2000s）。为了解决系统崩溃导致的数据损坏问题并支持更大容量，日志文件系统成为主流。代表技术包括 Linux 的 ext3/ext4、XFS 以及 Sun 的 ZFS，它们在保证高可靠性的同时，大幅提升了并行 I/O 处理能力。
- 大规模分布式阶段（2000s – 2010s）。互联网普及导致数据规模爆发式增长，传统单机文件系统面临共享和扩展的严峻挑战。业界发展出了 GFS、HDFS、Ceph 等分布式文件系统，其核心架构演进为“元数据与数据分离”，通过通用硬件集群实现了强大的横向扩展能力和容错性。
- 场景化与新型硬件适配阶段（2010s – 至今）。随着存储介质的多样化和算力架构的变革，文件系统开始向专用化和软硬协同方向演进。例如面向闪存优化的 F2FS、华为自研的只读文件系统 EROFS（广泛应用于 HarmonyOS）。而如今的 XMFS 则标志着文件系统正式迈入“超节点时代”，开始深度适配 CXL、内存池化等前沿硬件技术，以应对存算分离架构下的极致性能需求。
看到这个存算分离，不止是 ES、Kafka 等 Java 类中间件采用这项技术，硬件的发展也在向这个趋势靠近。“灵衢 UB”总线、“免序列化免拷贝数据直访”等细节技术，归纳起来就是大道至简，没有银弹。
为什么要做 XMFS？
2026 年 10 月初，我们在国庆放假，老外没有。这期间，在捷克布拉格，Linux Plumbers Conference 2026（LPC 2026）上，华为工程师端出了一个新东西 XMFS。这是一款专为现代 Linux 服务器设计的实验性文件系统。消息一出，国内外技术社区迅速围观，众多科技媒体称其“性能超越 TMPFS”。
XMFS 全称 eXpress Memory FS（极速内存文件系统），目标是通过标准 POSIX 文件接口，让跨节点共享内存可以被“直接访问”上层应用零改动。在内存池化、存算分离成为 AI 时代基础设施关键词的今天，这个定位非常耐人寻味。
在存算分离的大背景下，XMFS 应用而生。这其中，有两股主要的技术浪潮。
- 第一股浪潮：CXL 与内存语义互连。CXL 3.0 以及华为自研的统一总线“灵衢 UB”，都属于内存语义互连技术。它们让“远程内存像本地内存一样被直接寻址”成为可能——换句话说，内存不再绑定在某一台服务器的 CPU 上，而是可以池化、共享、按需分配。华为早在 2023 年的存算分离架构展望中就指出，CXL 能把网络时延压到亚微秒级，实现内存型介质的池化。
- 第二股浪潮：应用侧的“内存墙”。AI/HPC 训练、大规模容器调度、视频编解码 …… 这些负载对内存容量和共享效率的要求越来越高。传统做法里，每个节点要么各自把容器镜像、共享数据拷贝一份到本地内存（重复占用、冷启动慢），要么通过网络文件系统共享（序列化、拷贝、协议开销一个不少）。
华为在 2025 年 11 月的 CLK 大会上就披露过 XMFS 的初步成果。它基于内存语义实现免序列化、免拷贝的数据直访，读写性能接近本地 tmpfs，并在容器冷启动、视频编解码场景下有效降低“内存底噪”。这次登上 LPC 2026，则是它面向国际社区的完整首秀。
于是问题来了，既然 CXL/UB 已经把远程内存“搬”到了家门口，如何让应用无感、透明地用上它？这正是 XMFS 要回答的问题。
XMFS 一个 DFS 风格的分层架构
从大会公开的架构图看，XMFS 采用了一种 DFS（分布式文件系统）风格的分层设计，整个系统由下面三部分组成。
| 组件 | 职责 |
|---|---|
| Server | 元数据与空间分配：superblock 版本控制、inode table、append-only 日志槽位分配、负载均衡 |
| Client | 处理 POSIX 请求：与 Server 及内存池通信、日志回放（replay to catchup）、构建 inode table、写日志 |
| Memory Pool | 存数据：通常就是各客户端的内存，也可以是一个独立的解耦内存设备（disaggregated device）；负责数据存放、data slot 分配与 GC |
这套设计的关键思想是控制面与数据面分离，元数据集中管理（保证一致性、便于版本控制和垃圾回收），而真正的数据读写则在内存池上分布式完成。这样一来，元数据操作走日志通道，数据面走内存通道，互不拖累。
两种数据模式，全场景通吃
XMFS 架构上最值得称道的设计，是它针对不同硬件条件给出了两条数据通路，自动适配。
- 模式一：硬件缓存一致（CC）域内，极致性能路径。如果节点处于同一个硬件 CC 域（CXL 3.0 支持多节点一致共享内存，华为 UB 亦然），XMFS 的读写和 mmap 直接就是对内存池的
cache-line 级访问，映射之后零拷贝。节点之间通过位于共享内存中的MPMC（多生产者多消费者）消息环通信。这条路径完全不需要软件层面去维护一致性，性能天花板极高。 - 模式二：无硬件 CC，或 CC 成本太高，网络模式。没有硬件一致性支持时，XMFS 退回网络模式，远程读写不依赖 cache-line flush，代价是相比 LD/ST 多做几次数据拷贝，且不需要一致的地址空间。
两种模式共用同一套 POSIX 接口，应用完全无感。这种“有硬件 coherence 就吃满硬件红利，没有就优雅降级”的思路，在文件系统设计中并不常见。
与之配套，内存池本身也有两种形态，可以是集中式池（一个解耦的内存设备），也可以是聚合式池（每个节点贡献出自己的本地 DRAM，拼成一个逻辑池）。部署灵活性直接拉满。
性能与官方基准
文章配图参见我的公众号：https://mp.weixin.qq.com/s/TdzDItKXS23roOgox-w-aA。
根据 LPC 2026 公开的基础性能基准测试，XMFS 对比传统 TMPFS 表现“十分亮眼”。
- 4KB I/O 延迟对比中，XMFS 的读写延迟显著低于网络内存访问路径；
- 跨节点读扩展性测试显示，随着并发节点数增加，吞吐能持续爬升；
- 华为给出的总体口径是
读写性能接近本地 tmpfs，也就是说，它做到了“跨节点共享”和“本地内存速度”兼得。
最能说明问题的还是原型场景，多节点容器镜像共享。
传统方案里，Node A 和 Node B 启动同一个容器镜像时，各自从磁盘/本地缓存拉取一份完整镜像；XMFS 则把镜像只保留一份在内存池中，两个节点打开同一个文件、直接 LD/ST 访问镜像层，
没有第二次拉取（no second pull）。
实测结果显示，容器冷启动时间从基于本地磁盘的 3.25 秒降至 1.99 秒。
此外，针对元数据密集型工作负载（AI/HPC 场景里大量小文件、频繁元数据操作的典型形态），华为也已完成测试验证。换句话说，在容器化部署和 AI/HPC 负载中，XMFS 已具备实用价值，而非停留在纸面。
相比 FAMFS、DAXFS 强在哪？
其实 XMFS 并不是 CXL 文件系统的第一次尝试。业内已有 FAMFS、DAXFS 等面向 CXL 服务器的方案。XMFS 的差异点可以归纳为以下四个。
- 原生完整 POSIX，应用零改动。这是 XMFS 最核心的竞争力。此前多数 CXL 文件系统方案只提供有限的接口或需要应用适配；XMFS 则原生支持常规 POSIX 文件系统操作，应用不用改一行代码，挂载即用。对生态的意义远大于单项性能数字。
- 一致性“双模”架构。硬件 CC 域内走零拷贝 cache-line 直访 + MPMC 消息环；域外走不依赖 cache-line flush 的网络模式。一套代码覆盖两种硬件现实，这在文件系统设计中是一次结构性创新。
- 控制面/数据面分离 + append-only 日志。Server 集中管元数据和空间分配（superblock 版本控制、inode table、日志槽位分配、负载均衡），Client 无状态化处理 POSIX 请求，日志 append-only 设计让回放、追平（catchup）、故障恢复都变得简洁。
- 池化无关性。无论内存池是集中式解耦设备，还是各节点 DRAM 的聚合，XMFS 都能工作。这与“彻底存算解耦 + 远程内存池扩展本地内存”的新型存算分离架构高度契合。
实验性文件系统
热闹之余，也有几点需要泼冷水（或者说，保持观察），目前还在实验性阶段。
- 尚未进入主线。XMFS 目前仍处于实验阶段，还没有提交到 Linux 内核邮件列表（LKML）接受社区评审，距离主线合入尚有距离。其设计能否经受住社区对正确性、一致性和可维护性的拷问，是接下来的关键看点。
- 基准测试为华为单方数据。“接近本地 tmpfs”的口径来自官方演示，第三方复现与更严苛场景（写密集、故障注入）下的表现仍待观察。
- 命名容易混淆。值得注意的是，XMFS 与 SGI 时代的老牌日志文件系统 XFS 没有任何关系，后者是面向磁盘的高扩展文件系统，XMFS 是面向共享内存的池化文件系统。二者只差一个字母，千万别搞混。
- 硬件依赖是双刃剑。它的极致性能依赖 CXL 3.0 或华为灵衢 UB 这类内存语义互连硬件。在 CC 域之外退化为网络模式后，其价值更多体现在 POSIX 透明性上，性能优势会收窄。
结语
回顾这些年，华为先把 EROFS 做进了每一台安卓手机，又把欧拉、高斯带到了服务器与云；如今在 AI 基础设施的内存池化赛道上，XMFS 再次押注了“互连 + 操作系统”的协同创新。
XMFS 的亮相传递了一个清晰信号，当 CXL 和统一总线把内存变成可池化、可共享的资源后，文件系统这层“最后一公里”的软件抽象，值得被重新发明。POSIX 透明、免序列化、免拷贝、接近本地内存的速度——如果它最终能走完社区化的长征，容器启动、AI 数据管道、HPC 元数据操作等场景的工作方式，都可能被悄然改写。
当然，实验性三个字意味着一切才刚刚开始。后续需要持续关注它是否现身 LKML，以及社区评审中的火花。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » 3.25 秒到 1.99 秒，华为 XMFS 文件系统性能吊打 tmpfs