JuiceFS v1.1-beta2 今天正式发布，这个版本中，最值得关注的是新支持 Gluster 作为JuiceFS 的对象存储。
熟悉 JuiceFS 的用户都知道 JuiceFS 本身不直接存储数据，而是需要对接其他 “对象存储” 来负责底层数据的管理。目前，对于需要自建对象存储的用户而言，常见的选择是MinIO或Ceph。然而，这两者都存在一些不足之处。例如，MinIO 在大规模集群的扩容过程中可能会面临一些困难，而 Ceph 在处理集群故障时往往有较高的运维难度。
为了解决大规模集群扩容难和运维复杂的问题，我们在 v1.1-Beta2 这个版本中新增对 Gluster 的支持。
Gluster（或 GlusterFS，https://github.com/gluster/glusterfs）是一款开源的软件定义分布式存储，单集群能支持 PiB 级别的数据。2005年首次发布，至今已有十多年的历史，目前主要由 Red Hat 负责维护，在全球范围内拥有一定规模的用户群。
那为什么 Gluster + JuiceFS 能够让大规模集群的运维更简单呢？这主要得从两个角度分析：
1. Gluster
Gluster 的架构非常简单且完全去中心化，它直接在每个节点上使用本地文件系统（如 XFS ）来存储数据。得益于这种简洁的架构，Gluster 能够轻松地支持 PiB 级别的集群规模。此外，用户在使用和管理 Gluster 时也非常简单。
但它也存在几个问题：
- 大目录 list 比较慢：由于没有中心化的元数据管理服务，Gluster 客户端在 list 目录时需要将多个服务节点的结果整合起来展示，当目录很大时这个操作将会非常耗时；
- 副本一致性不强：Gluster 中的数据通常需要冗余（比如三副本）保存，但在极端情况下文件多次修改后可能出现多个副本间都不一致的情形；
- 文件重命名影响性能：Gluster 中通过文件名的 Hash 结果来确定存储节点，当文件被重命名后位置可能发生改变；然后 Gluster 会在期望位置创建一个链接指向该文件原来所在的实际位置，这在一定程度上会影响后续的文件查找性能。
2. JuiceFS
在日常使用时，JuiceFS 调用的对象存储接口非常简单，即基础的 HEAD/GET/PUT/DELETE；另外，JuiceFS 中数据对象只会写入一次，没有覆盖或者 append 写。
因此，可以认为上述 Gluster 的三个问题，在仅将其作为 JuiceFS 数据存储引擎的场景中都不会遇到。
鉴于以上两个角度的原因，JuiceFS 决定在这个版本中加入对 Gluster 的支持。
由于对接 Gluster 需要首先安装其对应的客户端软件包（类似 Ceph），因此默认发布的 JuiceFS 不能直接使用，而是需要用户手动构建，具体步骤可以参见。
其他新增功能：
新文件系统自动限制旧版本
在 v1.1 版本中，JuiceFS 添加了目录配额管理以及用量统计的功能，且这些功能对于新创建的文件系统会默认启用。然而，v1.1 之前的版本并没有这些功能，因此在使用时一方面不会受到目录配额的限制，另一方面也会导致用量统计出现较大的偏差。为防止用户在不知情情况下混用多个版本的客户端，JuiceFS 会在新建文件系统时自动添加限制，阻止 v1.1 之前的客户端连接。
对于已有的文件系统，目录配额及用量统计功能默认不启用，因此也不会有这个限制。不过如果用户需要使用目录配额，我们建议在设置配额前也能手动加上版本限制，如：
$ juicefs config $META-URL --min-client-version 1.1.0-ABug 修复
- 修复某些命令（如 warmup, rmr）在容器内可能会无法正常使用的问题
- 修复 info 命令查看很大文件时可能返回失败的问题
- 修复特定场景中在已删除的目录下仍能成功创建文件的问题
- 修复 stats 命令偶尔看不到对象存储（object）统计指标的问题
完整的Bug列表以及软件下载点此 。
相关阅读
