Lustre 是基于GNU GPL协议开源的分布式并行文件系统，目前主要是DDN维护。lustre由于非常容易扩展和极致的性能，常被用在超算、AI领域、视频存储等领域。lustre是通过内核的lustre客户端来访问文件对象。

Polefs是自研是360智汇云自主研发的一款面向云原生设计的高性能分布式文件系统。提供完全兼容POSIX标准的接口，通过自主研发的分布式缓存架构，深度融合NVMe高速存储介质，实现微秒级I/O延迟与百万级IOPS并发处理能力。同时引入低成本S3协议对象存储作为全域数据持久化载体，形成“热数据NVMe加速+冷数据S3沉降”的分层存储体系，实现性能与容量的双重弹性扩展。目前主要业务场景有AI 训练、大模型、容器平台等。

本文从架构设计、文件分布和功能特性等方面对 Lustre 和 PoleFS 进行全面对比。

架构对比

Luster

Luster主要由MGS和一个以上Lustre文件系统组成，核心组件如下：

管理服务器（MGS）：存储所有 Lustre 文件系统的配置信息，并把这些信息提供给其他组件。每个Lustre target链接MGS来提供信息，Lustre 客户端链接MGS来检索这些信息。

Lustre文件系统组成：

元数据服务器（MDS）元数据目标(Metadata Targets，MDT)：负责处理命名空间相关操作及存储元数据信息，如文件创建、删除、权限检查等。自 2.4 版本起引入了分布式命名空间（DNE）功能，支持将单个文件系统的不同目录分布在多个元数据服务器上，实现元数据访问负载的横向扩展。每个MDS管理Lustre文件系统中的名称和目录，并为一个或多个本地MDT提供网络请求处理。

对象存储服务器（OSS）对象存储目标(OST)：负责实际的数据读写，提供高性能的大规模 I/O 服务。用户文件数据存储在一个或多个对象中，每个对象存储在Lustre文件系统中单独的OST上。

客户端（Client）：为用户应用程序提供访问 Lustre 文件系统的接口，实现标准的 POSIX 文件操作语义。客户端软件包括MGC (management client)、MDC (metadata client)和多个OSCs (object storage client)，对应文件系统中的OST

Lustre官网组件图

Polefs

Polefs是360公司自主研发的一款面向云原生设计的高性能分布式缓存文件系统，采用模块化架构，包括元数据服务、缓存数据服务、数据存储服务、FUSE client、Java SDK、CSI Driver：

元数据服务：由Master和MetaNode节点组成，Master将负责卷和缓存信息的管理，包括创建、更新、查询、删除卷和缓存操作，MetaNode负责文件的元数据，每个独立的卷包含若干元数据的分区用来存储inode、Dentry、数据分布等信息，这些分区以分布式的形式尽量均衡地存储于元数据集群，元数据具备极易扩展，可支持超大目录的能力。

数据服务：由分布式缓存与支持S3协议的对象存储共同构建，其中对象存储提供低成本、高容量的数据持久化能力；缓存层采用独立的分布式架构，通过一致性哈希算法动态选取高性能节点，实现写入时的三副本缓存冗余与读取时的单副本高效访问机制。

客户端：提供多种接入方式，为上层业务提供不同的访问协议，最大限度满足用户的多样化需求。

架构差异

很多分布式文件系统的架构组成极为相似，重点看实现、组织、细节的差异。

客户端

PoleFS采用现代化的用户态实现架构，与传统的内核态文件系统相比，具有显著的设计优势。其客户端通过FUSE（Filesystem in Userspace）运行在用户空间，避免了复杂的内核态开发，使得系统更加稳定且易于维护。相比之下，某些传统文件系统如Lustre采用C语言实现，客户端运行在内核态，虽然在数据访问时减少了上下文切换开销，但带来了开发和维护的复杂性。

随着Linux内核版本的演进，特别是5.1版本对FUSE的优化，用户态文件系统的性能得到了显著提升。主要改进包括零拷贝传输、多线程处理、元数据缓存优化和异步I/O支持等技术，使得FUSE-based文件系统在5.1+内核环境下性能表现优异。

存储模块

         Lustre架构以共享存储为基础进行数据管理，其早期版本缺乏文件级别的容错机制（FLR），因此需要借助共享存储的高可用配置或软件层面的RAID技术来确保数据安全性；当计算节点出现故障离线时，必须将其重新挂载至备用节点，否则相关数据块将面临无法读取的风险；尽管较新版本已支持FLR功能，但不同副本间的数据一致性仍需人工干预进行验证；此外，该系统需要预先部署ldiskfs或ZFS等本地文件系统作为底层支撑。

Polefs：运用分布式缓存+对象存储的架构，数据最终落到对象存储，兼顾高性能、低成本的设计，并确保数据的稳定性和一致性，提供标准化对象操作接口，未来能够做到无缝集成各大主流云服务商以及MinIO、Ceph RADOS等私有化对象存储平台，通过本地缓存、分布式缓存多级缓存架构方式，有效满足AI计算场景下的高带宽需求。

元数据模块

就元数据管理体系而言，Lustre 与 Polefs 均构建了统一的命名空间架构并实现了文件元数据的集中化管控。

Lustre 的 MDS 容灾机制基于软硬件一体化架构实现：硬件维度：MDS 所使用的存储设备必须部署 RAID 阵列，防止单一磁盘故障引发的服务中断；存储介质还需具备共享特性，确保主节点失效时，备用节点能够顺利接管存储资源。 软件维度：通过 Pacemaker 与 Corosync 的组合构建容灾集群，保证任意时刻仅存在一个活跃的 MDS 服务实例。

Polefs 采用自主研发的高性能元数据引擎，将元数据信息inode、dentry、块分布等元信息按卷的维度，partition为实体以分布式的方式在集群中进行存储及管理，并优化其分布，例如dentry会和父目录inode在相同分区，在遍历目录时只需要访问一次元数据，Inode及块分布信息均匀分布在卷所有partition上，有效缓解大规模训练场景下元数据服务在特定节点形成瓶颈的状况。现阶段支持的数据量级可达到千亿规模。

文件分布对比

Lustre文件分布

lustre 是通过把一个文件分割为多个文件对象，然后存储在多个OST上的方式存储数据。文件的分割在lustre中叫做stripe。stripe有两种类型的布局，第一类是默认的正常(normal)文件布局；第二类是复合(composite)文件布局。

       正常(normal)文件布局的静态分布策略在灵活性和资源利用率方面存在明显限制，它的布局由stripe count和stripe size决定，stripe size表示一次写入的大小，stripe count表示使用多少个OST来存储这些文件片，例如写入7M的数据，stripe size为1M，stripe count为3，则写入顺序为，OST1（0-1M），OST2(1-2M)，OST3（2-3M），OST1(3-4M)，OST2（4-5M），OST3（5-6M），OST1（6-7M）。这样的分布方式，每个文件的条带被固定在特定的OST上，在使用过程中容易造成磁盘使用不均衡并因无法调整分布而持续恶化。

       复合(composite)文件布局，会有一些列的子布局数组组成，每个布局的stripe count和stripe size不同，为不同的的文件段采用不同的布局。例如文件大小低于某值时，采用stripe size 1M，stripe count 1来优化小文件访问效率，或者文件大小在某范围内时提升count个数，提高并发I/O能力，或者增大Stripe size来提高大文件高吞吐量的访问需求。这样组合方式的文件布局更灵活，适配各种场景需求，缓解磁盘不均衡问题但是不能根治。为了完全解决磁盘使用不均的问题，Lustre结合延迟分配机制，即首次写入不分配实际物理存储，当系统检测到磁盘不均时，针对尚未分配的文件区域动态指定新的分布策略，写入负载较轻的OST。

Polefs文件布局

       Polefs 文件布局与Juicefs相同，按照 Chunk、Slice、Block 的规则进行数据块管理。每个 Chunk 的大小固定为 64M，主要用于优化数据的查找和定位。实际的文件写入操作则在 Slice 上执行，每个 Slice 代表一次连续的写入过程，属于特定的 Chunk，并且不会跨越 Chunk 的边界，因此长度不超过 64M。Chunk 和 Slice 主要是逻辑上的划分，而 Block（默认大小为 4M）则是物理存储的基本单位，用于在对象存储和磁盘缓存中实现数据的最终存储。

每个文件由1个或多个Chunk组成，Chunk的存在是为了优化查找定位，每个Chunk最大64M，读写都会根据偏移量来定位Chunk，修改内容不会改变Chunk的切分。文件写入则是在slice上进行，若写入连续则一个slice属于1个chunk，若写入不连续或产生了随机，则可能多个slice即堆叠的slice，在的调用flush时这些slice将被持久化。在真正写入时，则按照设定的块大小拆分成若干个块，我们称这个块为needle，needle是写入分布式缓存及对象存储的基本存储单元。修改文件时会创建新的slice，并在更新元数据后，写入新的needle，无需重写整个文件，老的needle删除是个异步清理的过程。

这种布局方式更均衡、更灵活，整个系统的设计及使用复杂度低于lustre。系统的吞吐及平行度取决于分布式缓存的大小（可简单的动态调整）及块大小的设置（按卷的维度设置块的大小，lustre是按文件大小维度，在OST卷级别配置存储策略）。

功能特性对比

总结

Luster是一款高性能并行分布式文件系统，其构建了一套高性能并行分布式存储架构，其客户端以内核模式运行，能够直接与元数据服务节点（MDS）及对象存储节点（OSS）建立通信，消除了用户空间与内核空间的切换开销。配合高端存储硬件，Lustre 在大带宽输入输出场景中呈现出优异的性能表现。但运维复杂性提升，要求运维人员掌握深厚的内核调试技能和底层系统故障诊断能力，采用预分配容量的存储策略，文件布局设计较为繁复，需要精密的规划和配置以确保资源的最优利用，其安装部署与日常维护具有较高的技术门槛，依赖高性能的专用存储设备。

Polefs作为云原生的用户空间分布式文件系统，借鉴Juicefs、CubeFs等诸多优秀分布式文件系统的优点，设计了高性能分布式元数据集群，并采用分布式缓存+对象存储作为最终数据存储组件，整体基于多级缓存架构实现了高性能低成本的分布式缓存文件系统。客户端支持fuse、CSI及多种sdk接口，整体的设计和实现使得性能可弹性、成本可平衡。

两款系统各有所长：Lustre 在传统高性能计算环境中追求性能极限的表现十分突出，而 Polefs 在云原生和人工智能工作负载场景中更适合、更便捷，提供了良好的性能体验和成本收益。

参考文献：https://cloud.tencent.com/developer/article/2074593

https://juicefs.com/docs/zh/community/comparison/juicefs_vs_lustre

https://juicefs.com/zh-cn/blog/engineering/lustre-vs-juicefs

https://blog.csdn.net/weixin_43912621/article/details/134215133

https://www.lustre.org/.lustre

https://doc.lustre.org/lustre_manual.xhtml#understandinglustre

代码仓库：git://git.whamcloud.com/fs/lustre-release.git

https://juicefs.com/zh-cn/blog/engineering/lustre-vs-juicefs

https://juicefs.com/docs/zh/community/comparison/juicefs_vs_lustre