[开源分享] 仅需一个脚本就能将目录转 s3 服务， FluxonFS vs Alluxio 5x 吞吐
如今，从 AI 训练框架加载模型、日志系统归档，到个人 NAS 的轻量备份，S3 已经事实成为现代云原生和 AI 工具链的标准对象存储接口。过去提到自建 S3，全球开发者的默认选项是 MinIO——高性能、S3 兼容、部署简单。但过去几年，MinIO 的一系列操作让社区逐渐离心：License 从宽松的 Apache 2.0 变为严苛的 AGPLv3，开源版接连砍掉 Console 管理控制台，商业化收紧的意图越来越明显。对于许多中小团队和个人开发者来说，MinIO 确实有些 "不行了"。
在这个生态位空缺的窗口期，RustFS 应运而生，刚好完美补上了这个位置。它用 Rust 重写了对象存储的核心，凭借无 GC 停顿、编译期内存安全的特性，提供了极高的并发性能和极低的延迟，以及良好的社区运营，迅速成为替代 MinIO 的优秀标杆。
但无论是 MinIO 还是 RustFS，它们本质上都是独立的对象存储系统。数据一旦写入，就会被系统接管，转化为内部格式和分片目录。这在构建大规模企业级集群时优势明显，但在个人使用、轻量级开发或本地 AI 调试场景中，却带来一种割裂的体验——你无法用 ls 直接查看文件分布，无法用 grep 快速检索日志，无法用 rsync 直接迁移数据。
大家在使用一些简单的网络存储组件时可能会面临一个矛盾：**既需要标准 S3 接口兼容现代工具链，又需要数据以普通文件形式存在，以便使用 `ls`、`grep`、`rsync` 等 Linux 工具直接处理。**
**典型场景：**
- **AI 训练与推理**：框架或周边工具通过 `s3://` 加载模型与数据集，工程师用本地工具检查占用或调试配置。
- **日志与备份**：业务程序通过 S3 SDK 写入，运维人员用本地工具排查和分发。
- **轻量开发与个人 NAS**：直接复用现有目录，无需部署独立对象存储；数据可随时通过 `tar` 或 `rsync` 迁移。
**常见方案的局限：**
- **MinIO 等对象存储**：提供 S3 接口，但数据目录由服务自身管理，不适合绕过服务直接读写。
- **HTTP / FTP**：可直接访问文件，但缺少 SigV4 鉴权、Multipart Upload 等 S3 语义。
- **NFS / SMB**：保留文件访问方式，但无法为只支持 S3 的应用提供入口。
## FluxonFS 的解决思路：本地文件系统作为真相源，Fluxon 仅作接口转换和缓存加速
针对上述局限，需要一种既提供标准 S3 接口，又不接管数据管理、仍允许直接操作底层文件的方案。在统一数据访问与缓存加速领域，Alluxio 是这一理念的开创者之一：它证明了通过统一接口层和智能缓存，可以有效解耦上层应用与底层存储。
围绕“协议转换 + 访问加速”，业界长期存在多条技术路径：NFS、SMB 将远程文件系统暴露给本地客户端； s3fs 等 FUSE 工具把远程 S3 bucket 挂载为本地目录； Ceph、JuiceFS 等存储系统通过自身的数据与元数据层提供文件和 S3 等多种访问接口； RustFS 等对象存储则专注于提供高性能的 S3 兼容入口。它们解决的问题相近，但映射方向和权威数据源不同：
| 技术路径 | 典型方案 | 权威数据源 | 主要特点 |
|----------|-----------|-------------|-----------|
| 远程文件系统 → 本地文件接口 | NFS、SMB | 远程文件系统 | 提供文件语义，但不能直接满足只支持 S3 的应用 |
| S3 对象存储 → 本地文件接口 | s3fs | S3 对象存储 | 通过 FUSE 模拟文件访问，底层对象存储仍是真相源 |
| 自有存储系统 → 多协议接口 | Ceph、JuiceFS | 系统自身的数据与元数据层 | 同时提供文件和对象入口，但数据由该存储系统管理 |
| 自有对象存储 → S3 接口 | MinIO、RustFS | 对象存储自身 | 提供原生 S3 服务，但不以现有普通目录作为权威数据源 |
| 现有本地目录 → 多协议接口 | Alluxio、FluxonFS | 本地普通文件 | 无需迁移或转换数据，增加多协议入口并复用缓存、共享内存和 RDMA 能力 |
FluxonFS 属于上表第五类：它直接叠加在现有本地目录之上，不要求数据迁移到新的存储格式。**本地文件系统始终是唯一权威数据源（Single Source of Truth）；FluxonFS 不接管数据管理，只在其上提供多协议访问与缓存加速。**本文聚焦其中的标准 S3 接口。
在此基础上，FluxonFS 复用 Fluxon 底层的 KV 缓存、共享内存和 RDMA 数据通路，在保持数据归属不变的同时，加速热点对象和跨节点访问。
FluxonFS 不会接管、封装或隐藏数据，而是直接叠加在现有本地目录之上：
- **接口转换**：处理 SigV4 鉴权、Multipart Upload 等 S3 语义，并将 S3 请求实时转换为对本地文件的 POSIX 读写。
- **权限管控**：基于 S3 协议附加多租户身份认证与访问权限管理，为本地目录增加统一的服务侧安全边界。
- **缓存加速**：利用内置 KV 缓存加速热点数据访问；缓存不参与权威数据管理，可随时丢弃或重建。
- **高性能数据通路**：复用 Fluxon 底层的 RDMA 与共享内存能力；节点内通过共享内存减少数据复制，节点间可通过 RDMA 降低传输开销。
这意味着：
- **对 S3 客户端**：看到的是标准的 `s3://` bucket，可以正常上传、下载和列举对象。
- **对本地用户**：数据始终以普通文件形式保存在磁盘上，可以随时使用 `ls`、`grep`、`rsync` 等 Linux 工具直接操作。
这种设计实现了零数据迁移与双向透明，适合现代 AI 工作流和轻量级运维场景。
## FluxonFS S3 读写性能
下面是在同一台开发机上，使用 `rclone v1.60.1` 对 FluxonFS S3 和 Alluxio S3 Proxy 进行的单机对比。两套服务均重复执行 3 次；共完成 162 个测试案例，文件内容、实际磁盘读写字节和干扰检查全部通过。
- **测试规模**：2,000 × 4 KiB、256 × 1 MiB、32 × 256 MiB（共 8 GiB），并发为 1、8、32，每组运行 3 轮。
- **持久化 PUT**：源文件位于 `/dev/shm`；计时包含上传和目标 NVMe 文件系统的 `syncfs`，不只统计 HTTP 返回时间。
- **冷读**：数据从 NVMe 读取到 `/dev/shm`；每组开始前重启服务并通过 `POSIX_FADV_DONTNEED` 驱逐文件页缓存，FluxonFS 关闭异步缓存回填，Alluxio 使用 `NO_CACHE`。
- **热读**：两套服务的应用层内存缓存上限均设为 64 GiB，实际载入约 8.26 GiB 测试数据。先将数据完整载入 Fluxon KV shared memory 或 Alluxio Worker MEM，并完成一次不计时的 S3 GET；随后仅驱逐底层 NVMe 文件的 Linux 页缓存，不清除上述应用缓存。计时期间要求后端 NVMe 读取量为 0。
图中的柱高为三轮算术均值。4 KiB 小文件使用 `objects/s`，1 MiB 和 256 MiB 文件使用 `MiB/s`；各文件大小面板采用独立纵轴，冷读与热读在同一面板内共用纵轴。
### 持久化 PUT 、冷读与热读汇总图
*图注：第一行是持久化 PUT；第二行在同一纵轴内合并冷读和热读。每个并发档位依次排列 FluxonFS 冷读、Alluxio 冷读、FluxonFS 热读、Alluxio 热读；下方百分比中，绿色表示 FluxonFS 领先，红色表示 FluxonFS 落后。*
### 测试结果结论
1. **FluxonFS 在持久化 PUT 与冷读的全部 18 组组合中均快于 Alluxio。** 持久化 PUT 的领先幅度为 36%～726%，冷读的领先幅度为 7%～661%。
2. **小文件和中文件在并发访问下收益最明显。** 4 KiB 冷读在并发 1、8、32 下分别达到 605、3,539 和 4,259 objects/s；1 MiB 冷读在并发 32 下达到 1,145 MiB/s，约为 Alluxio 的 7.6 倍。
3. **大文件冷读更接近底层 NVMe 吞吐上限。** FluxonFS 在并发 1、8、32 下分别领先约 7%、19% 和 42%；优势仍然存在，但不像小文件和中文件那样显著。
4. **热读中，小文件高并发优势最明显，中大文件整体接近。** FluxonFS 的 4 KiB 对象吞吐领先约 8%～43%；1 MiB 在并发 8 时领先约 19%，并发 1 和 32 时与 Alluxio 相差不足 1%；256 MiB 在三种并发下的差异不超过约 1.2%。
## 目录、对象与缓存如何对应
上述设计通过 FluxonFS 的 `export` 模式落地：`export_name` 对应 bucket，导出根目录下的相对路径对应 object key。
---
原文链接：[点击查看](https://www.v2ex.com/t/1233228)
在这个生态位空缺的窗口期，RustFS 应运而生，刚好完美补上了这个位置。它用 Rust 重写了对象存储的核心，凭借无 GC 停顿、编译期内存安全的特性，提供了极高的并发性能和极低的延迟，以及良好的社区运营，迅速成为替代 MinIO 的优秀标杆。
但无论是 MinIO 还是 RustFS，它们本质上都是独立的对象存储系统。数据一旦写入，就会被系统接管，转化为内部格式和分片目录。这在构建大规模企业级集群时优势明显，但在个人使用、轻量级开发或本地 AI 调试场景中，却带来一种割裂的体验——你无法用 ls 直接查看文件分布，无法用 grep 快速检索日志，无法用 rsync 直接迁移数据。
大家在使用一些简单的网络存储组件时可能会面临一个矛盾：**既需要标准 S3 接口兼容现代工具链，又需要数据以普通文件形式存在，以便使用 `ls`、`grep`、`rsync` 等 Linux 工具直接处理。**
**典型场景：**
- **AI 训练与推理**：框架或周边工具通过 `s3://` 加载模型与数据集，工程师用本地工具检查占用或调试配置。
- **日志与备份**：业务程序通过 S3 SDK 写入，运维人员用本地工具排查和分发。
- **轻量开发与个人 NAS**：直接复用现有目录，无需部署独立对象存储；数据可随时通过 `tar` 或 `rsync` 迁移。
**常见方案的局限：**
- **MinIO 等对象存储**：提供 S3 接口，但数据目录由服务自身管理，不适合绕过服务直接读写。
- **HTTP / FTP**：可直接访问文件，但缺少 SigV4 鉴权、Multipart Upload 等 S3 语义。
- **NFS / SMB**：保留文件访问方式，但无法为只支持 S3 的应用提供入口。
## FluxonFS 的解决思路：本地文件系统作为真相源，Fluxon 仅作接口转换和缓存加速
针对上述局限，需要一种既提供标准 S3 接口，又不接管数据管理、仍允许直接操作底层文件的方案。在统一数据访问与缓存加速领域，Alluxio 是这一理念的开创者之一：它证明了通过统一接口层和智能缓存，可以有效解耦上层应用与底层存储。
围绕“协议转换 + 访问加速”，业界长期存在多条技术路径：NFS、SMB 将远程文件系统暴露给本地客户端； s3fs 等 FUSE 工具把远程 S3 bucket 挂载为本地目录； Ceph、JuiceFS 等存储系统通过自身的数据与元数据层提供文件和 S3 等多种访问接口； RustFS 等对象存储则专注于提供高性能的 S3 兼容入口。它们解决的问题相近，但映射方向和权威数据源不同：
| 技术路径 | 典型方案 | 权威数据源 | 主要特点 |
|----------|-----------|-------------|-----------|
| 远程文件系统 → 本地文件接口 | NFS、SMB | 远程文件系统 | 提供文件语义，但不能直接满足只支持 S3 的应用 |
| S3 对象存储 → 本地文件接口 | s3fs | S3 对象存储 | 通过 FUSE 模拟文件访问，底层对象存储仍是真相源 |
| 自有存储系统 → 多协议接口 | Ceph、JuiceFS | 系统自身的数据与元数据层 | 同时提供文件和对象入口，但数据由该存储系统管理 |
| 自有对象存储 → S3 接口 | MinIO、RustFS | 对象存储自身 | 提供原生 S3 服务，但不以现有普通目录作为权威数据源 |
| 现有本地目录 → 多协议接口 | Alluxio、FluxonFS | 本地普通文件 | 无需迁移或转换数据，增加多协议入口并复用缓存、共享内存和 RDMA 能力 |
FluxonFS 属于上表第五类：它直接叠加在现有本地目录之上，不要求数据迁移到新的存储格式。**本地文件系统始终是唯一权威数据源（Single Source of Truth）；FluxonFS 不接管数据管理，只在其上提供多协议访问与缓存加速。**本文聚焦其中的标准 S3 接口。
在此基础上，FluxonFS 复用 Fluxon 底层的 KV 缓存、共享内存和 RDMA 数据通路，在保持数据归属不变的同时，加速热点对象和跨节点访问。
FluxonFS 不会接管、封装或隐藏数据，而是直接叠加在现有本地目录之上：
- **接口转换**：处理 SigV4 鉴权、Multipart Upload 等 S3 语义，并将 S3 请求实时转换为对本地文件的 POSIX 读写。
- **权限管控**：基于 S3 协议附加多租户身份认证与访问权限管理，为本地目录增加统一的服务侧安全边界。
- **缓存加速**：利用内置 KV 缓存加速热点数据访问；缓存不参与权威数据管理，可随时丢弃或重建。
- **高性能数据通路**：复用 Fluxon 底层的 RDMA 与共享内存能力；节点内通过共享内存减少数据复制，节点间可通过 RDMA 降低传输开销。
这意味着：
- **对 S3 客户端**：看到的是标准的 `s3://` bucket，可以正常上传、下载和列举对象。
- **对本地用户**：数据始终以普通文件形式保存在磁盘上，可以随时使用 `ls`、`grep`、`rsync` 等 Linux 工具直接操作。
这种设计实现了零数据迁移与双向透明，适合现代 AI 工作流和轻量级运维场景。
## FluxonFS S3 读写性能
下面是在同一台开发机上，使用 `rclone v1.60.1` 对 FluxonFS S3 和 Alluxio S3 Proxy 进行的单机对比。两套服务均重复执行 3 次；共完成 162 个测试案例，文件内容、实际磁盘读写字节和干扰检查全部通过。
- **测试规模**：2,000 × 4 KiB、256 × 1 MiB、32 × 256 MiB（共 8 GiB），并发为 1、8、32，每组运行 3 轮。
- **持久化 PUT**：源文件位于 `/dev/shm`；计时包含上传和目标 NVMe 文件系统的 `syncfs`，不只统计 HTTP 返回时间。
- **冷读**：数据从 NVMe 读取到 `/dev/shm`；每组开始前重启服务并通过 `POSIX_FADV_DONTNEED` 驱逐文件页缓存，FluxonFS 关闭异步缓存回填，Alluxio 使用 `NO_CACHE`。
- **热读**：两套服务的应用层内存缓存上限均设为 64 GiB，实际载入约 8.26 GiB 测试数据。先将数据完整载入 Fluxon KV shared memory 或 Alluxio Worker MEM，并完成一次不计时的 S3 GET；随后仅驱逐底层 NVMe 文件的 Linux 页缓存，不清除上述应用缓存。计时期间要求后端 NVMe 读取量为 0。
图中的柱高为三轮算术均值。4 KiB 小文件使用 `objects/s`，1 MiB 和 256 MiB 文件使用 `MiB/s`；各文件大小面板采用独立纵轴，冷读与热读在同一面板内共用纵轴。
### 持久化 PUT 、冷读与热读汇总图
*图注：第一行是持久化 PUT；第二行在同一纵轴内合并冷读和热读。每个并发档位依次排列 FluxonFS 冷读、Alluxio 冷读、FluxonFS 热读、Alluxio 热读；下方百分比中，绿色表示 FluxonFS 领先，红色表示 FluxonFS 落后。*
### 测试结果结论
1. **FluxonFS 在持久化 PUT 与冷读的全部 18 组组合中均快于 Alluxio。** 持久化 PUT 的领先幅度为 36%～726%，冷读的领先幅度为 7%～661%。
2. **小文件和中文件在并发访问下收益最明显。** 4 KiB 冷读在并发 1、8、32 下分别达到 605、3,539 和 4,259 objects/s；1 MiB 冷读在并发 32 下达到 1,145 MiB/s，约为 Alluxio 的 7.6 倍。
3. **大文件冷读更接近底层 NVMe 吞吐上限。** FluxonFS 在并发 1、8、32 下分别领先约 7%、19% 和 42%；优势仍然存在，但不像小文件和中文件那样显著。
4. **热读中，小文件高并发优势最明显，中大文件整体接近。** FluxonFS 的 4 KiB 对象吞吐领先约 8%～43%；1 MiB 在并发 8 时领先约 19%，并发 1 和 32 时与 Alluxio 相差不足 1%；256 MiB 在三种并发下的差异不超过约 1.2%。
## 目录、对象与缓存如何对应
上述设计通过 FluxonFS 的 `export` 模式落地：`export_name` 对应 bucket，导出根目录下的相对路径对应 object key。
---
原文链接：[点击查看](https://www.v2ex.com/t/1233228)
评论
暂无评论。