DeepSeek 3FS解读与源码分析（5）：客户端解读

已于 2025-04-07 09:45:34 修改
阅读量1.2k 收藏 14
点赞数 13
CC 4.0 BY-SA版权
分类专栏： DeepSeek 3FS解读与源码分析 文章标签： 人工智能 大模型 大数据 算法
于 2025-03-19 14:41:30 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/DB_GPT/article/details/146369430

客户端模式

3FS 实现了两套客户端模式，FUSE Client和Native Client。前者更方便适配，性能相对较差。后者适合集成性能敏感的应用程序，适配成本较高。接下来做进一步分析。

Fuse Client

Fuse Client 模式的原理如下图所示。和传统 FUSE 应用类似，在 libfuse 中注册了 FUSE Daemon 实现的 fuse_lowlevel_ops，之后通过 FUSE 的所有的文件操作，都会通过 libfuse 回调到 FUSE Daemon 进行处理。同时在 libfuse 中实现了一个多线程模式来高效读取请求。这种模式对于业务逻辑影响较小，可以做到无感知。但是每次 I/O 单向需要经过两次“用户态-内核态”上下文切换，以及“用户空间-内核空间”之间数据拷贝。

图片

Native Client （USRBIO）

介绍这个模式之前我们先了解一下 User Space Ring Based IO（简称 USRBIO）[1]，它是一组构建在 3FS 上的高速 I/O 函数。用户应用程序能够通过 USRBIO API 直接提交 I/O 请求给 FUSE Daemon 进程中的 3FS I/O queue 来和 FUSE 进程通信，从而做到 kernel bypass。两者之间通过基于共享内存 ior/iov 的机制交换数据，这部分在后面章节介绍。Native Client 模式的原理如下图所示。使用这种模式能有效避免“用户态-内核态”上下文切换，同时做到零数据拷贝，全链路基本无锁化设计，性能上要比 Fuse Client 模式提升很多。（根据我们对 3FS 开源的 fio ioengine hf3fs_usrbio 压测结果看，在不进行参数调优的情况下，USRBIO 比 **Fuse Client **模式顺序写性能提升 20%-40%，其他场景性能还在进一步验证中）

3FS 使用 Pybind 定义 Python 扩展模块 hf3fs_py_usrbio，这也方便 Python 能够访问 hf3fs 的功能。以此推测 USRBIO 模式适合在大模型训练和推理等对性能有极致需求的场景中使用。

图片

另外，从上面分析我们注意到 Fuse Daemon 在两种客户端模式下都起到核心作用的重要组件。在 Fuse Client 模式中，它通过 fuseMainLoop 创建 FuseClients，注册 fuse 相关 op 的 hook，并根据配置拉起单线程（或多线程） fuse session loop 处理 fuse op。在 USRBIO 模式中，与 I/O 读写链路相关的 USRBIO API 通过共享内存和 Fuse Daemon 通信，部分与 I/O 无关的控制路径请求例如 hardlink，punchhole 等，USRBIO API 则还是通过 ioctl 直接走了内核 FUSE 路径。这可能是一个 tradeoff 的设计，后面会做讨论。

基础组件

ServerLauncher

Fuse Daemon 也就是 FuseApplication， 通过 core::ServerLauncher 拉起。同样的还有 MgmtdServer，MetaServer，StorageServer 都是类似的 Daemon。Fuse Daemon 拉起之后就创建一个 FuseClients 进行核心功能操作。

图片

FuseClients

一个 FuseApplication 包含 一个 FuseClients，一个 FuseClients 和一个挂载点对应。FuseClients 主要包括下图所示组件，其中包含与其他组件（meta，mgmtd，storage）打交道的 "client for client"。FuseClients 在启动时也会初始化 mgmtdClient，创建 StorageClient，metaClient，启动周期性 Sync Runner（用来更新文件长度等元数据），创建 notifyInvalExec 线程池等。同时还为每一个 FuseClients 创建一组 IOV 和 IOR。FuseClients 最重要的部分还是在和 USRBIO 协同设计。下面我们着重分析这部分。

图片

USRBIO 的设计和思考

3FS USRBIO 设计思想借鉴了 io_uring 以及 SPDK NVMe 协议栈的设计。原生 io_uring [2] 由一组 Submission Queue 和 Completion Queue 组成，每个 queue 是一个 ring buffer。用户进程提交请求到 SQ，内核选择 polling 模式或事件驱动模式处理 SQ 中的请求，完成之后内核向 CQ 队尾 put 完成 entry，应用程序根据 polling 模式或者事件驱动模式处理 CQ 队首的请求。整个过程无锁，共享内存无内存拷贝。在 polling 模式下，io_uring 接近纯用户态 SPDK polling mode 性能，但是 io_uring 需要通过额外的 CPU cost 达到这个效果。

图片

3FS USRBIO 的核心设计围绕 ior 和 iov 来开展。 ior 是一个用于用户进程与 FUSE 进程之间通信的小型共享内存环。用户进程将读/写请求入队，而 FUSE 进程从队列中取出这些请求并完成执行。ior 记录的是读写操作的元数据，并不包含用户数据，其对应的用户数据 buffer 指向一个叫做 iov 的共享内存文件。这个 iov 映射到用户进程和 FUSE 进程共享的一段内存，其中 InfiniBand 内存注册由 FUSE 进程管理。在 USRBIO 中，所有的读取数据都会被读取到 iov，而所有的写入数据应由用户先写入 iov。

ior 用来管理 op 操作任务，和 io_uring 不同的是这个 queue 中既包括提交 I/O 请求（sqe）又接收完成 I/O 结果（cqe），而且不通过 kernel，纯用户态操作。ior 中包含的 sqeSection 和 cqeSection 的地址范围由创建 ring 的时候计算出来的 entries 个数确定，用来查询 sqe 和 cqe 在 ring 中的 位置。ior 中还包含一个 ringSection，这个 section 用来帮助 sqe 定位 iov id 的索引和位置。

如下图所示，sqe 里包含 idx 是 IOArgs* ringSection 这个数组的下标，索引后才是真正的 io 参数。例如：seq -> ringSection[idx] -> IovId -> Iov。

图片

USRBIO 中提供了一个 API hf3fs_iorwrap 用来创建和管理 ior，其中 Hf3fsIorHandle 用来管理 ior。之后 hf3fs_iorwrap 会通过 cqeSem 解析 submit-ios 信号量的路径，并通过 sem_open 打开关联信号量，用于 I/O 任务同步。这里的信号量根据优先级被放置在不同目录中。之后在提交 IO 过程中，会 post 信号量通知 cqe section 中 available 的 slots。

图片

在 ior 中，通过 IoRingJob 分配工作，任务被拆分成 IoRingJob，每个任务会处理一定数量的 I/O 请求做批处理。和 io_uring 一样，采用 shared memory 减少用户态与内核态切换。

  1. 1. IoRing 初始化资源

  2. 2. 提交 I/O 请求 addSqe

  3. 3. 获取待处理的 I/O 任务 IoRing::jobsToProc

  4. 4. 处理 I/O 任务 IoRing::process，如上图所示。

IoRing::process() -->ioExec.addWrite() --> ioExec.executeWrite()
--> ioExec.finishIo()

图片

图片

IoRing 中的 ioExec 就是 PioV。PioV::executeWrite() 执行写操作中根据是否需要 truncate chunk，选择将 truncate WriteIO 包到一个 std::vectorstorage::client::WriteIO wios2中，或者直接传输std::vectorstorage::client::WriteIO wios_，最后通过 StorageClient::batchWrite() 将 Write IO 通过发送 RPC 写请求到 Storage 端。其中，写请求 WriteReq 包括 payload，tag，retryCount，userInfo，featureFlags 等字段。

FuseClients 中最核心的逻辑之一在 ioRingWorker 中。它负责从 FuseClients 的 ior job queue 中拿到一个 ior，并调用 process 处理它。在处理过程中考虑了取消任务的设计，这里使用了一个 co_withCancellation 来封装，它能够在异步操作中优雅地处理任务取消，避免不必要的计算或资源占用，并且支持嵌套任务的取消感知。有关 co_cancellation 的原理可以参考 [3]：

图片

另外，还支持可配置的对任务 job 分优先级，优先级高的 job 优先处理。这些优化都能在复杂的场景下让性能得到极致提升。值得提到的一点是，所有的 iovs 共享内存文件在挂载点 3fs-virt/iovs/ 目录下均建有 symlink，指向 /dev/shm 下的对应文件。

图片

USRBIO 代码逻辑错综复杂，偏差之处在所难免，在这里抛砖引玉一些阅读代码的思路和头绪，如有错误也请不吝批评指正。

关于USRBIO的思考

USRBIO 在共享内存设计上使用了映射到物理内存的一个文件上，而不是使用匿名映射到物理内存。这可能是因为用户进程和 FUSE Daemon 进程不是父子进程关系。实现非派生关系进程间的内存共享，只能使用基于文件的映射或 POSIX 共享内存对象。

USRBIO 没有采用直接以 SDK 形式，放弃 Fuse Daemon，直接和元数据服务器与 Chunk Server 来通信的方式设计客户端，而采用了关键 I/O 路径使用纯用户态共享内存，非关键路径上依旧复用 libfuse 这种方式。这可能是简化控制链路设计，追求 FUSE 上的复用性，追求关键路径性能考虑。另外在 IoRing 的设计上并没有使用类似 io_uring 中的可配置的 polling 模式，而是采用信号量进行同步，这里暂时还没有理解背后的原因是什么。

USRBIO 使用共享内存还是不可避免会带来一些开销和性能损耗，如此设计的本质原因还是所有核心逻辑都做在了 FUSE Daemon 进程中。如果提供重客户端 SDK，所有逻辑都实现在 SDK 中，以动态连接库形式发布给客户端，可能就不需要进行这样的 IoRing 设计，或者只需要保留 io_uring 这样的无锁设计，不再需要共享内存设计。这样的好处和坏处都很鲜明：好处是 SDK 的实现能避免跨进程的通信开销，性能能达到理想的极限；坏处是如果需要保留 FUSE 功能的话需要实现两套代码，逻辑还很雷同，带来较大的开发和维护成本。而且 SDK 的升级比较重，对客户端造成的影响相对较大。当然从工程角度上可以由 FUSE 抽象出公共函数库让 Native Client 直接调用也可以避免重复开发。

目前这么做猜测可能是先做的 FUSE，后面再提供的 Native Client，这样采用现有方案是个比较水到渠成的过程，整体投入产出比可控。 这同时也是 USRBIO 方案的好处，它的客户端这一侧 API 相对较薄，逻辑也相对稳定，没有太多升级的压力，另外 Fuse 进程承担了和元数据以及 Storage 的通信，这样对上层推理或者训练业务的影响也就会较小。总体来说，USRBIO 方案是在易用性（FUSE 升级相对容易）、研发效率（简单化管控面）和性能（只针对 I/O 路径）这三个方面上做的一个权衡。

在大模型训练和推理技术蓬勃发展的今天，存储越来越贴近计算是一个必然的发展趋势。特别是在训练侧的 checkpoint，尽可能地让数据更快地从 GPU 写入到远端存储，能大大提升整体性能。目前在 3FS USRBIO 路径上没有看到 GPU Direct Storage / GPU Direct RDMA / GPU Direct Async 被使用，考虑到一个可能原因是 folly 协程库在 nvcc 下编译有问题。协程虽然在计算密集型业务中带来的性能提升不明显，但对于 I/O 密集型业务由于避免了线程切换的开销能带来较大提升，这个点上相信 DeepSeek 做过较深入的对比和考量。

另外，我们也从 DeepSeek 开源的 DeepEP 上看到在跨 NVLink 域 和 RDMA 域高性能通信的可能性，是否在存储框架上也能实现与上层训练和推理框架更紧密地结合，畅想一下 3FS 和大模型存储业界未来可能打造出诸如 User Space GPU Based IO（USGBIO）这样的存储组件来。

StorageClient

StorageClient 是客户端和 Storage 进行 RPC 通信的重要组件。StorageClientImpl 是其中实际工作的模块，它在启动的时候会拉起来若干组件：包括一个存储用的 StorageMessenger，一个Update用的 StorageMessenger，初始化MgmtdClient。

StorageClientImpl::selectRoutingTargetForOps() 中会选择 servingTargets。同时 StorageClient 中有一个 StorageMessenger，通过调用 callSerdeRpcMethod 发送请求到 Storage。

图片

图片

Targets 选择

在 batchRead，batchWrite，queryLastChunk，removeChunks，truncateChunks 操作中都涉及到选择 routing targets。

selectRoutingTargetForOps-->TargetSelectionStrategy::create(options) --> targetSelectionStrategy->selectAnyTarget()

客户端选择 Target 策略 有若干种类型可供配置选择：

图片

Batch 和 Parallel

在 batchRead，batchWrite，queryLastChunk，removeChunks，truncateChunks 操作中均涉及到 batch 操作。这部分逻辑使用 groupOpsByNodeId 将输入的请求根据不同 NodeId 做 group 聚合，生成了一个根据 NodeId 组成的 Op* 数组的这样一个 pair 的数组，最后通过 processBatches 把它们发送出去。在 processBatches 中巧妙利用 folly::coro::Task 和 collectAllRange 来实现了并行执行操作。

图片

参考材料

[1] 3FS USRBIO 官方参考文档 

https://github.com/deepseek-ai/3FS/blob/main/src/lib/api/UsrbIo.md

[2] Why you should use io_uring for network I/O | Red Hat Developer

[3] DeepSeek SF-ZHOU 关于 folly coro cancellation 的技术博客

https://sf-zhou.github.io/coroutine/folly_coro_cancellation.htm

Hudi源码|Insert源码分析总结（一）(整体流程)
主要分享大数据相关的知识，如Spark、Hudi
11-11 3871
Hudi Java Client总结|读取Hive写Hudi代码示例。以Java Client为例的原因：1、自己生产上用的Java Client，相比于Spark客户端更熟悉一点。2、Java Client和Spark、Flink客户端核心逻辑是一样的。不同的是比如Spark的入口是DF和SQL，多了一层API封装。3、Java Client更贴近源码，可以直接分析核心逻辑。不用剖析Spark、Flink源码。对Sprk、Flink源码不熟悉的更容易上手。
deepseek v3网络结构源码分析笔记
u012160945的博客
02-08 1692
简单说来就是一种新的计算QKV的方式，原始的QKV计算是通过3个矩阵运算对hidden state分别计算QKV，KV需要缓存在网络中，现在通过一个中间步骤计算QKV，不直接缓存KV而是缓存下图阴影部分，减少了 K 和 V 矩阵的存储和计算开销。计算最终输出的时候有“navie”和“absorb”方式，代码实际用的是absorb方式，区别在于navie模式模型存贮cache的是k和v，而absorb方式存储的是kv_cache和pe_cache。2. TransformerBlock结构：和上图类似。
DeepSeek 3FS解读与源码分析（3）：Storage模块解读
DB_GPT的博客
03-14 1536
2025年2月28日，DeepSeek 正式开源其颠覆性文件系统Fire-Flyer 3FS（以下简称3FS），重新定义了分布式存储的性能边界。本文将结合代码和design_notes 对storage部分进行分析和探讨。
DeepSeek源码剖析：MoE架构与MLA工程化实现全解析
最新发布
2401_85375298的博客
06-07 1022
本书是一本系统讲解DeepSeek源码及其核心实现原理的技术指南，内容覆盖了从基础概念到高级应用的全流程知识。全书共7章，结构层层递进。第1章对DeepSeek进行了全面概述，帮助读者构建对DeepSeek系统的整体认知。第2章聚焦于环境搭建、代码获取与模型部署接入，为后续深入研究提供基础。第3章深入探讨了MoE（混合专家模型）的基本原理、功能模块与优化技术。第4章详细解析了DeepSeek-V3模型的架构知识，并通过测试验证展示了系统的实际效果。
DeepSeek 3FS解读与源码分析（1）：高效训练之道
DB_GPT的博客
03-04 1516
https://github.com/deepseek-ai/3FS/blob/main/docs/design_notes.md3FS 满足 AI 处理过程中的大部分场景：Training data preprocessing数据集的预处理需求。Dataset loading训练过程中的数据集读取需求 。Checkpointing训练过程中，高并发 checkpoint 文件的写入。KVCache for Inference为 KVCache 提供了比 DRAM 更加经济的替代方案，提供更低的成本和更大的
Deepseek 3FS解读与源码分析（2）：网络通信模块分析
DB_GPT的博客
03-04 2215
本文基于 3FS 网络通信模块的机制原理和源代码进行了初步分析。整体来说 3FS 的实现涉及到非常多的细节优化，通信模块和存储模块的设计环环相扣，交相呼应，展示了极高水平的存储架构设计。
DeepSeek源码解析（1）
weixin_43506403的博客
02-14 1460
使用 import name 时，你需要通过模块名来访问其中的内容，适合导入整个模块。使用 from name import name 时，你可以直接使用导入的内容，适合导入模块中的特定部分。使用 from name import * 时，你可以直接使用模块中的所有内容，但容易引起命名冲突，需谨慎使用。选择哪种导入方式取决于你的具体需求和代码的可读性。二、 整数除法 //
Cephfs架构解读和测试分析
10-26
Cephfs架构解读与测试分析主要内容如下： 1. Cephfs简介 Cephfs是Ceph存储系统提供的一个分布式文件系统，它兼容POSIX协议，允许用户以标准文件系统的方式存取数据。与Ceph的其他组件RBD（块存储）和RGW（对象存储...
Hhadoop-2.7.0中HDFS写文件源码分析（二）：客户端实现（1）
辰辰爸的博客
12-19 5582
一、综述      HDFS写文件是整个Hadoop中最为复杂的流程之一，它涉及到HDFS中NameNode、DataNode、DFSClient等众多角色的分工与合作。      首先上一段代码，客户端是如何写文件的：Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(conf); Path file
XV6源码解读：安装与编译
JDongChen的博客
07-23 5449
系列文章目录 提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加 例如：第一章 Python 机器学习入门之pandas的使用 提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档 文章目录系列文章目录一、Xv6介绍二、编译1.从`make qemu`开始2.编译`kernel`生成可执行文件总结 一、Xv6介绍 Xv6是MIT6.S081教学用的操作系统。 Xv6源码下载： git clone git://github.com/mit-pdos/xv6-riscv.git
vue转electron项目以及使用fs报错：Module not found: Error: Can‘t resolve ‘fs‘ in解决办法
热门推荐
feinifi的博客
09-16 2万+
vue项目转electron手动操作需要在命令行下运行vue add electron-builder，在使用node依赖开发桌面程序的时候，需要把node集成进来，配置nodeIntegration变量。
DeepSeek源码解析（2）
weixin_43506403的博客
02-17 1347
在计算机科学和机器学习领域，“张量”（Tensor）是一个数学概念，它被用来表示多维数组。在大模型（如深度学习模型）中，张量扮演着核心角色，具体来说：数据表示：张量用于表示输入数据、模型参数和中间计算结果。例如，在图像处理中，一张图片可以被表示为一个三维张量（高度、宽度、颜色通道数），而在自然语言处理中，一段文本可以被编码为一系列词向量组成的二维张量（句子长度、词向量维度）。线性代数运算：深度学习中的许多操作，如卷积、全连接等，都可以看作是线性代数中的矩阵运算。这些操作在底层通过张量进行计算。
深度解读DeepSeek：源码解读 DeepSeek-V3
造梦先森Kai的专栏
03-21 945
输入tokens → embed → 添加位置编码 → 逐层Block处理 → norm → head → 输出logits。此步骤对应下面DeepSeek V3技术架构图，核心即MLA和MoE。
DeepSeek 3FS 技术解析与实战指南
weixin_44727517的博客
03-14 1390
DeepSeek 3FS（Fire-Flyer File System）是一款面向 AI 训练与推理场景设计的高性能并行文件系统，通过融合现代 SSD 存储与 RDMA 网络技术，实现高达6.6TiB/s的吞吐量，支撑数据预处理、检查点保存、KVCache 查询等关键场景23。
DeepSeek 3FS 架构分析和思考（上篇）
volcenginetod的博客
03-25 1139
通过固定切分 chunk 的方式，能够有效的规避数据读写过程中与 Meta Service 的交互次数，降低元数据服务的压力，但是也引入另外一个弊端，即对写容错不够友好，当前写入过程中，如果一个 chunk 写失败，是不支持切下一个 chunk 继续写入的，只能在失败的 chunk 上反复重试直到成功或者超时失败。火山引擎文件存储团队阅读和分析了 3FS 的设计文档和源代码，总结出这篇文章，在介绍了 3FS 关键设计的同时，尝试从存储专业的视角挖掘出 3FS 团队在这些设计背后的考量。
DeepSeekV3报告及代码解读
DYF的博客
02-13 1409
DeepSeekV3报告及代码解读
DeepSeek-V3 核心架构源码讲解
日常学习与专研的记录
03-05 2143
文本详细讲解 DeepSeek-V3 的核心架构的源码。
DeepSeek V3 源码：从入门到放弃！
极客BIM工作室
03-06 6043
这段代码定义了一个多头注意力层（MLA）类。在初始化时，根据传入的参数设置各种维度、低秩投影的秩等，并初始化相应的线性层和归一化层，同时根据注意力实现方式注册不同的缓存。在前向传播过程中，对输入进行处理得到查询、键和值，应用旋转位置编码，根据不同的注意力实现方式计算注意力分数，最后通过注意力分数和缓存得到输出并进行线性变换。这段代码定义了一个混合专家（MoE）模块。在初始化时，根据传入的参数设置专家的数量、门控机制、专家模块列表和共享专家模块。
DeepSeek 3FS解读与源码分析专栏收录该内容5 篇文章订阅专栏客户端模式3FS 实现了两套客户端模式，FUSE Client和Native Client。前者更方便适配，性能相对较差。后者适合集成性能敏感的应用程序，适配成本较高。接下来做进一步分析。Fuse ClientFuse Client 模式的原理如下图所示。和传统 FUSE 应用类似，在 libfuse 中注册了 FUSE Daemon 实现的 fuse_lowlevel_ops，之后通过 FUSE 的所有的文件操作，都会通过 libfuse 回调到 FUSE Daemon 进行处理。同时在 libfuse 中实现了一个多线程模式来高效读取请求。这种模式对于业务逻辑影响较小，可以做到无感知。但是每次 I/O 单向需要经过两次“用户态-内核态”上下文切换，以及“用户空间-内核空间”之间数据拷贝。Native Client （USRBIO）介绍这个模式之前我们先了解一下 User Space Ring Based IO（简称 USRBIO）[1]，它是一组构建在 3FS 上的高速 I/O 函数。用户应用程序能够通过 USRBIO API 直接提交 I/O 请求给 FUSE Daemon 进程中的 3FS I/O queue 来和 FUSE 进程通信，从而做到 kernel bypass。两者之间通过基于共享内存 ior/iov 的机制交换数据，这部分在后面章节介绍。Native Client 模式的原理如下图所示。使用这种模式能有效避免“用户态-内核态”上下文切换，同时做到零数据拷贝，全链路基本无锁化设计，性能上要比 Fuse Client 模式提升很多。（根据我们对 3FS 开源的 fio ioengine hf3fs_usrbio 压测结果看，在不进行参数调优的情况下，USRBIO 比 **Fuse Client **模式顺序写性能提升 20%-40%，其他场景性能还在进一步验证中）3FS 使用 Pybind 定义 Python 扩展模块 hf3fs_py_usrbio，这也方便 Python 能够访问 hf3fs 的功能。以此推测 USRBIO 模式适合在大模型训练和推理等对性能有极致需求的场景中使用。另外，从上面分析我们注意到 Fuse Daemon 在两种客户端模式下都起到核心作用的重要组件。在 Fuse Client 模式中，它通过 fuseMainLoop 创建 FuseClients，注册 fuse 相关 op 的 hook，并根据配置拉起单线程（或多线程） fuse session loop 处理 fuse op。在 USRBIO 模式中，与 I/O 读写链路相关的 USRBIO API 通过共享内存和 Fuse Daemon 通信，部分与 I/O 无关的控制路径请求例如 hardlink，punchhole 等，USRBIO API 则还是通过 ioctl 直接走了内核 FUSE 路径。这可能是一个 tradeoff 的设计，后面会做讨论。基础组件ServerLauncherFuse Daemon 也就是 FuseApplication， 通过 core::ServerLauncher 拉起。同样的还有 MgmtdServer，MetaServer，StorageServer 都是类似的 Daemon。Fuse Daemon 拉起之后就创建一个 FuseClients 进行核心功能操作。FuseClients一个 FuseApplication 包含 一个 FuseClients，一个 FuseClients 和一个挂载点对应。FuseClients 主要包括下图所示组件，其中包含与其他组件（meta，mgmtd，storage）打交道的 "client for client"。FuseClients 在启动时也会初始化 mgmtdClient，创建 StorageClient，metaClient，启动周期性 Sync Runner（用来更新文件长度等元数据），创建 notifyInvalExec 线程池等。同时还为每一个 FuseClients 创建一组 IOV 和 IOR。FuseClients 最重要的部分还是在和 USRBIO 协同设计。下面我们着重分析这部分。USRBIO 的设计和思考3FS USRBIO 设计思想借鉴了 io_uring 以及 SPDK NVMe 协议栈的设计。原生 io_uring [2] 由一组 Submission Queue 和 Completion Queue 组成，每个 queue 是一个 ring buffer。用户进程提交请求到 SQ，内核选择 polling 模式或事件驱动模式处理 SQ 中的请求，完成之后内核向 CQ 队尾 put 完成 entry，应用程序根据 polling 模式或者事件驱动模式处理 CQ 队首的请求。整个过程无锁，共享内存无内存拷贝。在 polling 模式下，io_uring 接近纯用户态 SPDK polling mode 性能，但是 io_uring 需要通过额外的 CPU cost 达到这个效果。3FS USRBIO 的核心设计围绕 ior 和 iov 来开展。 ior 是一个用于用户进程与 FUSE 进程之间通信的小型共享内存环。用户进程将读/写请求入队，而 FUSE 进程从队列中取出这些请求并完成执行。ior 记录的是读写操作的元数据，并不包含用户数据，其对应的用户数据 buffer 指向一个叫做 iov 的共享内存文件。这个 iov 映射到用户进程和 FUSE 进程共享的一段内存，其中 InfiniBand 内存注册由 FUSE 进程管理。在 USRBIO 中，所有的读取数据都会被读取到 iov，而所有的写入数据应由用户先写入 iov。ior 用来管理 op 操作任务，和 io_uring 不同的是这个 queue 中既包括提交 I/O 请求（sqe）又接收完成 I/O 结果（cqe），而且不通过 kernel，纯用户态操作。ior 中包含的 sqeSection 和 cqeSection 的地址范围由创建 ring 的时候计算出来的 entries 个数确定，用来查询 sqe 和 cqe 在 ring 中的 位置。ior 中还包含一个 ringSection，这个 section 用来帮助 sqe 定位 iov id 的索引和位置。如下图所示，sqe 里包含 idx 是 IOArgs* ringSection 这个数组的下标，索引后才是真正的 io 参数。例如：seq -> ringSection[idx] -> IovId -> Iov。USRBIO 中提供了一个 API hf3fs_iorwrap 用来创建和管理 ior，其中 Hf3fsIorHandle 用来管理 ior。之后 hf3fs_iorwrap 会通过 cqeSem 解析 submit-ios 信号量的路径，并通过 sem_open 打开关联信号量，用于 I/O 任务同步。这里的信号量根据优先级被放置在不同目录中。之后在提交 IO 过程中，会 post 信号量通知 cqe section 中 available 的 slots。在 ior 中，通过 IoRingJob 分配工作，任务被拆分成 IoRingJob，每个任务会处理一定数量的 I/O 请求做批处理。和 io_uring 一样，采用 shared memory 减少用户态与内核态切换。1. IoRing 初始化资源2. 提交 I/O 请求 addSqe3. 获取待处理的 I/O 任务 IoRing::jobsToProc4. 处理 I/O 任务 IoRing::process，如上图所示。IoRing::process() -->ioExec.addWrite() --> ioExec.executeWrite()--> ioExec.finishIo()IoRing 中的 ioExec 就是 PioV。PioV::executeWrite() 执行写操作中根据是否需要 truncate chunk，选择将 truncate WriteIO 包到一个 std::vectorstorage::client::WriteIO wios2中，或者直接传输std::vectorstorage::client::WriteIO wios_，最后通过 StorageClient::batchWrite() 将 Write IO 通过发送 RPC 写请求到 Storage 端。其中，写请求 WriteReq 包括 payload，tag，retryCount，userInfo，featureFlags 等字段。FuseClients 中最核心的逻辑之一在 ioRingWorker 中。它负责从 FuseClients 的 ior job queue 中拿到一个 ior，并调用 process 处理它。在处理过程中考虑了取消任务的设计，这里使用了一个 co_withCancellation 来封装，它能够在异步操作中优雅地处理任务取消，避免不必要的计算或资源占用，并且支持嵌套任务的取消感知。有关 co_cancellation 的原理可以参考 [3]：另外，还支持可配置的对任务 job 分优先级，优先级高的 job 优先处理。这些优化都能在复杂的场景下让性能得到极致提升。值得提到的一点是，所有的 iovs 共享内存文件在挂载点 3fs-virt/iovs/ 目录下均建有 symlink，指向 /dev/shm 下的对应文件。USRBIO 代码逻辑错综复杂，偏差之处在所难免，在这里抛砖引玉一些阅读代码的思路和头绪，如有错误也请不吝批评指正。关于USRBIO的思考USRBIO 在共享内存设计上使用了映射到物理内存的一个文件上，而不是使用匿名映射到物理内存。这可能是因为用户进程和 FUSE Daemon 进程不是父子进程关系。实现非派生关系进程间的内存共享，只能使用基于文件的映射或 POSIX 共享内存对象。USRBIO 没有采用直接以 SDK 形式，放弃 Fuse Daemon，直接和元数据服务器与 Chunk Server 来通信的方式设计客户端，而采用了关键 I/O 路径使用纯用户态共享内存，非关键路径上依旧复用 libfuse 这种方式。这可能是简化控制链路设计，追求 FUSE 上的复用性，追求关键路径性能考虑。另外在 IoRing 的设计上并没有使用类似 io_uring 中的可配置的 polling 模式，而是采用信号量进行同步，这里暂时还没有理解背后的原因是什么。USRBIO 使用共享内存还是不可避免会带来一些开销和性能损耗，如此设计的本质原因还是所有核心逻辑都做在了 FUSE Daemon 进程中。如果提供重客户端 SDK，所有逻辑都实现在 SDK 中，以动态连接库形式发布给客户端，可能就不需要进行这样的 IoRing 设计，或者只需要保留 io_uring 这样的无锁设计，不再需要共享内存设计。这样的好处和坏处都很鲜明：好处是 SDK 的实现能避免跨进程的通信开销，性能能达到理想的极限；坏处是如果需要保留 FUSE 功能的话需要实现两套代码，逻辑还很雷同，带来较大的开发和维护成本。而且 SDK 的升级比较重，对客户端造成的影响相对较大。当然从工程角度上可以由 FUSE 抽象出公共函数库让 Native Client 直接调用也可以避免重复开发。
04-08
### DeepSeek 3FS 架构设计与源码分析 #### 1. 概述 DeepSeek 3FS 是一种专门为大规模分布式存储系统设计的文件系统，其核心设计理念围绕着高性能读带宽展开。为了实现这一目标，3FS 在多个方面进行了权衡，例如牺牲随机写性能、元数据操作效率以及部分 POSIX 兼容性来换取更高的吞吐量和更低的延迟[^1]。 #### 2. 架构设计特点 3FS 的架构主要分为以下几个模块： - **FUSE Daemon**: 提供了一个用户空间接口，允许开发者通过标准文件系统 API 访问底层对象存储服务。 - **I/O Queue**: 用户应用可以直接向 FUSE Daemon 中的 I/O 队列提交请求，减少传统文件系统的开销。 - **Shared Memory Mechanism**: 利用共享内存技术在客户端和服务端之间传递数据，避免了不必要的上下文切换和数据复制。 #### 3. USRBIO 性能优化原理 User Space Ring Based IO (USRBIO) 是建立在 3FS 基础上的高效 I/O 子系统。它的主要优势在于绕过了内核层处理逻辑，实现了真正的 zero-copy 和 lock-free 设计。具体来说： - **Kernel Bypass**: 应用程序无需经过操作系统内核即可完成 I/O 操作，显著降低了 CPU 使用率并提高了响应速度[^2]。 - **Zero Copy**: 数据传输过程中不需要额外缓冲区参与，减少了内存占用和访问次数。 - **Lock-Free Design**: 整条路径几乎没有任何同步原语介入，极大提升了并发能力。 以下是 USRBIO 实现的一个简化伪代码示例： ```c struct usrbio_request { char *buffer; size_t length; }; void submit_io(struct usrbio_queue *queue, struct usrbio_request req) { spin_lock(&queue->lock); list_add_tail(&req.list_entry, &queue->pending_requests); spin_unlock(&queue->lock); wake_up(queue->worker_thread); // Notify worker thread to process the request. } ``` #### 4. Fuse Client vs Native Client (USRBIO) | 特性 | Fuse Client | Native Client (USRBIO) | |---------------------|--------------------------------------|---------------------------------------| | 上下文切换 | 多次进入退出内核 | 完全规避 | | 数据拷贝 | 至少两次 | 不发生 | | 并发控制 | 锁较多 | 几乎无锁 | | 性能表现（顺序写） | 较低 | 提升约20%-40% | 上述表格总结了两种模式的关键差异点。可以看出，在追求极致性能的应用场景中，采用 Native Client 方案无疑更具竞争力。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值