背景

阿里云对象存储 OSS 是一款海量、安全、低成本、高可靠的云存储服务，是用户在云上存储数据的高性价比选择，在北京、上海、杭州、深圳、新加坡地域提供单账号高达 100Gbps 的下载带宽，可以很好地满足客户日益增长的带宽需求。

在 K8s 集群部署的业务若需要像操作本地文件一样读写在云端的 OSS 数据，需要将 OSS 类型的存储卷挂载至容器内。OSS 原生仅提供 RESTful 的 API 访问接口，因此挂载依赖基于 FUSE (filesystem in userspace) 接口的客户端，它负责将业务的 POSIX 协议操作转译成对象存储服务端的 RESTful 请求，使业务无需做额外改造，即可像访问本地文件系统一样访问 OSS 数据。

因此，FUSE 客户端的性能直接影响数据读写的整体效率。在 AI 等大数据业务场景中，相较于传统应用负载，有文件数量庞大（训练）、大文件读取性能要求高（推理）等典型特征，为避免 GPU 闲置，需尽量缩短数据加载与写入时间，对 FUSE 客户端的访问性能提出了更高要求，建立高速高效的访问通道至关重要。

从 OSSFS 1.0 到 2.0

ACK 集群存储插件此前接入的是 OSSFS 1.0 客户端^【1】，其基于开源项目 S3FS-FUSE 演化而来，支持了较为完整的 POSIX 语义：

除基础数据访问功能外，OSSFS 1.0 版本通过在对象的自定义元数据里记录了如 UID 等信息，从而具备文件系统级用户鉴权、软链接管理、扩展属性操作等功能；
OSSFS 1.0 版本通过引入本地磁盘缓存，支持了完整的写入能力（顺序写、随机写）实现了业务无需修改即可直接操作远程数据的需求。

这些特性使 OSSFS 1.0 客户端在需要通过挂载方式访问对象存储的通用读写场景发挥了重要价值。

然而，随着 AI 业务的发展，我们发现 AI 场景有下面几个典型特征：

推理场景需加载大模型文件，关注大文件读取的能力；
训练场景读取的数据集庞大，关注元数据的缓存能力、小文件并发加载的能力；
训练场景还会生成模型文件，关注大文件顺序写的能力；
不关注 POSIX 权限/软链接/扩展属性/重命名文件夹/随机写的能力。

而 OSSFS 1.0 版本由于设计上追求较为完备的 POSIX 语义，以及架构设计和实现上的选择，应对上述场景往往性能达不到预期：

为了支持 POSIX 权限/软链接/扩展属性等信息，OSSFS 1.0 版本需要频繁地发送 HeadObj 请求获取最新的元数据。
为支持随机写，OSSFS 1.0 版本数据读写需要落盘，在容器场景通常落到系统盘（默认一般为 P0 或 P1 级别的 ESSD 云盘）。相对于节点的网络带宽和 OSS 吞吐能力，磁盘 I/O 性能成为瓶颈，尤其在 Serverless 场景中问题更显著。而在 AI 场景，通常仅需要对检查点做顺序写操作。

尽管 OSSFS 1.0 客户端已提供 readdir_optimze（忽略扩展信息）和 direct_read（直读模式，避免数据落盘）等优化模式^【2】，可在特定场景提升性能，但其原始设计目标与架构设计仍难以完全满足 AI 场景的性能需求。此外，由于 OSSFS 1.0 版本基于开源项目 S3FS-FUSE 实现，其历史遗留的架构设计与工程实现使其很难大改以针对 AI 特定场景优化。

对此，阿里云存储团队推出全新的 OSSFS 2.0 客户端^【3】，作为在 AI 等高性能场景中的解决方案。

OSSFS 2.0 客户端针对 AI 训练、推理等关键场景，舍弃对对象存储不友好的文件权限以及随机写等 POSIX 语义兼容能力，转而聚焦于发挥 OSS 的原生高带宽能力。通过重新设计元数据架构、充分利用 FUSE 模块原生能力、引入阿里云自研的协程化技术，OSSFS 2.0 客户端对大文件顺序读写、大规模小文件并发读写实现了针对性的优化，也全面提升了客户端对 CPU 资源的利用率：

不追求完整的 POSIX 兼容性，仅维护基本的文件属性，如 mtime 和 size，面对大规模文件时无需频繁发送 HeadObj 请求，既减轻服务端压力，也提升客户端性能。
基于 FUSE3 Low Level API 重构：
元数据缓存管理更加灵活，查询、淘汰的性能更好；
可以利用到更底层的 API，减少线程切换和数据拷贝次数，提升读写性能。
引入了阿里云内部研发的协程化技术，显著提升并发效率与负载吞吐，并降低 CPU 资源使用。

总结起来，AI 场景下，与 OSSFS 1.0 客户端相比，OSSFS 2.0 客户端具有以下核心优势：

更加轻量化的协议设计：减少 OSS 元数据请求数量，专注于释放 OSS 服务端的读写能力。
大文件顺序读写优化：通过端到端读写链路重构，实现高效的大文件顺序访问。
小文件并发加速：依托高效的元数据管理系统，显著提升小文件加载并发能力。
资源精细化管理：在同等 CPU/内存资源下，通过资源分配优化保障高性能输出。

OSSFS 2.0 具备业界领先的读写性能，尤其适合机器学习训练等对高吞吐数据访问要求严苛的场景，满足不同负载对于挂载 OSS 的需求。而对于对 POSIX 文件属性有高需求，或需要支持随机写等通用场景，OSSFS 1.0 则是更合适的选择。

性能测试

使用 OSSFS 1.0 客户端、OSSFS 2.0 客户端挂载 Bucket 存储空间后，分别对基本的读写能力和模拟 AI 推理场景在单节点上进行测试。

读写能力测试

运用 FIO 测试工具，分别针对基本顺序读写能力展开测试。测试场景与结果如下：

单线程顺序写 100 GB 文件

ossfs版本	带宽	CPU核心占用率（单个核心满载为100%）	峰值内存
ossfs 2.0	2.2 GB/s	207%	2167 MB
ossfs 1.0	118 MB/s	5%	15 MB

单线程顺序读 100 GB 文件

ossfs版本	带宽	CPU核心占用率（单个核心满载为100%）	峰值内存
ossfs 2.0	3.0 GB/s	378%	1617 MB
ossfs 1.0	355 MB/s	50%	400 MB

4 线程顺序读 100 GB 文件

ossfs版本	带宽	CPU核心占用率（单个核心满载为100%）	峰值内存
ossfs 2.0	7.1 GB/s	1187%	6.2 GB
ossfs 1.0	1.4 GB/s	210%	1.6 GB

128 线程并发读 10 万 128 KB 小文件

ossfs版本	带宽	CPU核心占用率（单个核心满载为100%）	峰值内存
ossfs 2.0	1 GB/s	247%	212 MB
ossfs 1.0	3.5 MB/s	3%	200 MB

ossfs 2.0 相较于 ossfs 1.0 在顺序读写和高并发小文件读取方面均实现了显著的性能提升。

顺序写入性能：在单线程大文件顺序写入场景下，ossfs 2.0 的带宽相较于 ossfs 1.0 提升了近 18 倍。
顺序读取性能：

在单线程大文件顺序读取场景下，ossfs 2.0 的带宽相较于 ossfs 1.0 提升了约 8.5 倍。
在多线程（4 线程）大文件顺序读取场景下，ossfs 2.0 的带宽相较于 ossfs 1.0 提升了 5 倍以上。
小文件并发读取性能：在高并发（128 线程）读取小文件的场景下，ossfs 2.0 的带宽相较于 ossfs 1.0 提升了 280 倍以上。

详细的测试环境、挂载参数以及测试命令请参考性能测试文档^【4】

AI 推理场景模拟: safetensors 模型加载

safetensors 格式模型的加载机制存在特殊性：模型文件在读取时遵循一种带规律性跳跃的随机读模式。具体而言，加载过程需要根据权重分布特征，以特定偏移量分块读取数据，而非连续线性访问。然而，现有大部分存储客户端在处理此类读取模式时，会因无法识别跳跃规律而退化为纯随机读，导致 I/O 吞吐显著下降，成为模型加载速度的瓶颈。

OSSFS 2.0 客户端对 safetensors 等带偏移量读取模式进行了优化。

测试中，使用 hugging face 框架在 CPU 模式加载 safetensors 格式模型 Qwen2.5-72B-Instruct。具体详情如下：

节点机型：ecs.g7.32xlarge (128vCPU 512GiB)

测试场景：在Qwen-2.5-72B模型文件加载的AI推理场景下，在CPU环境下使用vllm库的LLM函数加载模型，对比OSSFS 1.0与OSSFS 2.0客户端的性能。

测试数据：Qwen-2.5-72B模型文件，约134.5GB（约4GB文件 * 37个，safetensors格式）。

OSSFS 1.0客户端开启了直读模式，测试中的配置参数为：

-odirect_read -odirect_read_prefetch_chunks=256 -odirect_read_prefetch_limit=8192 -odirect_read_backward_chunks=256 -odirect_read_chunk_size=16

OSSFS 2.0 客户端使用默认参数。

ossfs版本	耗时
ossfs 2.0	130s
ossfs 1.0	1135s

在 ACK 集群使用 OSSFS 2.0 存储卷

目前阿里云容器服务官方存储插件 CSI^【5】已支持挂载 OSS 存储卷时切换至 OSSFS 2.0 客户端^【6】，使用方式与此前基本一致，以下展示了 OSSFS 2.0 存储卷的存储卷（PV, PersistentVolume）与存储声明（PVC, PersistentVolumeClaim）的 YAML 文件，通过部署 YAML 文件即可在集群中创建相应的资源。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-ossfs2
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-ossfs2 # 需要和PV名字一致。
    # 使用预先创建的存储鉴权信息的secret，配置方式与原OSSFS 1.0存储卷一致。
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      fuseType: ossfs2 # 固定，声明使用的是OSSFS 2.0客户端
      bucket: cnfs-oss-test # bucket名称
      path: /subpath # 挂载的bucket子路径
      url: oss-cn-hangzhou-internal.aliyuncs.com # bucket的域名
      otherOpts: "-o close_to_open=false" # OSSFS 2.0客户端的配置参数
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-ossfs2
  namespace: default
spec:
  # 以下配置需要与PV一致
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 20Gi
  volumeName: pv-ossfs2

部署后，应用即可通过挂载 pvc-ossfs2 存储声明，在容器中通过 OSSFS 2.0 客户端访问 OSS 数据。OSSFS 2.0 存储卷同时支持静态挂载和动态挂载两种方式，具体使用方式请参考 OSSFS 2.0 存储卷使用文档^【7】，OSSFS 2.0 客户端支持的配置参数可参考配置文档^【8】。

总结

OSSFS 2.0 存储卷针对机器学习、自动驾驶、基因分析等高性能大数据场景进行了深度优化，与 OSSFS 1.0 存储卷相比实现了显著的性能突破。

ACK 已支持多位内外部客户针对 OSSFS 2.0 存储卷进行业务压力测试，并在实际业务场景中展现出高达数十倍的吞吐量提升，充分验证了其在高并发、高带宽需求下的稳定性与高效性。如需进一步验证其性能表现，欢迎在 ACK 集群中部署并测试 OSSFS 2.0 存储卷，以释放更极致的数据访问能力。

附：ACK 集群 OSS 存储卷选型参考

场景	存储卷	官方文档
读写或需要配置用户权限等绝大部分场景。	OSSFS 1.0存储卷	^【9】
只读或只包括顺序追加写的场景。如推理、训练集加载、自动驾驶等。	OSSFS 2.0 存储卷	^【6】
海量小文件只读，且OSS远端数据较少更新。如训练、量化回测、时序日志分析等。	StrmVol 存储卷	^【10】
读写可分离场景，即读写操作不同时进行或操作不同文件。如断点保存、日志持久保存等。	拆分不同的存储卷，如使用ossfs2.0存储卷挂载只读路径，使用ossfs1.0存储卷挂载写路径。