共计 4354 个字符，预计需要花费 11 分钟才能阅读完成。
咱们很快乐地发表 JuiceFS v1.1-Beta 版本正式公布啦！这是一个功能丰富的版本，带来了许多实用的新性能和改良。在这个版本中咱们新增了以下性能：
- 目录配额：为目录设置配额限度，管制其大小和文件数
- 目录克隆：疾速地复制目录及其内容，节省时间和空间
- 一键复原回收站文件：一次性地复原某段时间内所有被删除的文件，无需一一操作
- 一键收集诊断信息：一键生成诊断报告，不便排查问题和反馈意见
- 疾速查看用量信息：疾速查看存储空间和文件数的统计信息
此外，咱们还新增了一个元数据引擎 FoundationDB，一个反对分布式事务的 Key-Value 存储。
本次版本，共有 57 位社区贡献者参加奉献了 726 次提交，感激每一位的付出。
上面，咱们将具体介绍这个版本的新性能和变动。
目录配额
配额 能够用来限度文件系统中存储空间的最大可用量，避免因个别用户占用过多而影响整个零碎的稳定性。在之前版本中，JuiceFS 只反对文件系统级别的配额。这样一来，当这个文件系统被多用户共享应用时，管理员就无奈无效地管制每个用户的使用量。因而，在 v1.1 版本中，咱们为 JuiceFS 减少了 目录配额 的性能。具体来说，管理员能够依据须要为任意目录设置一个配额阈值（硬限度），之后如果此目录的使用量达到或超过该阈值，任何试图新建或扩大文件的申请都将失败，直到用户删除局部已有文件或管理员进步配额阈值。另外，为目录设置配额还有一个益处，就是能够让 JuiceFS 跟踪并记录它的应用状况，并在须要时疾速获取此目录及其子目录下所有文件的用量统计信息。
目录配额 的治理须要借助于新的 juicefs quota 命令，其设置参数与现有的文件系统配额统一，通过 --capacity <val> 来限度容量和通过 --inodes 来限度文件数。例如：
$ juicefs quota set $METAURL --path /test --capacity 1
+-------+---------+---------+------+-----------+-------+-------+
| Path | Size | Used | Use% | Inodes | IUsed | IUse% |
+-------+---------+---------+------+-----------+-------+-------+
| /test | 1.0 GiB | 1.6 MiB | 0% | unlimited | 314 | |
+-------+---------+---------+------+-----------+-------+-------+以上命令为 /test 目录设置了 1 GiB 的容量配额，且同时能够看到该目录下已使用量为 1.6 MiB。因为为目录新建配额时，须要递归统计该目录下以后的使用量，因而为已有的大目录设置配额可能须要期待较长时间。如果想查问某个目录的配额及其以后用量，能够应用 quota get 子命令，如：
$ juicefs quota get $METAURL --path /test
+-------+---------+---------+------+-----------+-------+-------+
| Path | Size | Used | Use% | Inodes | IUsed | IUse% |
+-------+---------+---------+------+-----------+-------+-------+
| /test | 1.0 GiB | 1.6 MiB | 0% | unlimited | 314 | |
+-------+---------+---------+------+-----------+-------+-------+此外，也能够应用 quota ls 子命令来查看所有曾经设置的配额。
值得注意的是，目录配额的统计并不是实时更新的，而是有肯定的提早。这样做是为了尽量减少对业务性能的影响。因而，可能呈现这样的状况：目录用量曾经达到配额阈值，但局部客户端在短时间（10 秒级别）内依然能够写入。同时，如果客户端过程异样退出，其长期记录的用量信息可能还没有同步给元数据引擎，导致信息不精确。为了解决这个问题，JuiceFS 提供了 quota check 子命令，能够在必要时查看并修复配额中的统计值，如：
$ juicefs quota check $METAURL --path /test --repair
+-------+---------+---------+------+-----------+-------+-------+
| Path | Size | Used | Use% | Inodes | IUsed | IUse% |
+-------+---------+---------+------+-----------+-------+-------+
| /test | 1.0 GiB | 3.2 MiB | 0% | unlimited | 317 | |
+-------+---------+---------+------+-----------+-------+-------+文件数的限度与其相似，在此不再赘述，具体应用可参考：https://juicefs.com/docs/zh/community/guide/quota/#%E7%9B%AE%…。
目录克隆
有时候，用户可能须要将一些文件复制进去用于其余目标。如果文件量不大，能够间接用 cp 命令来实现。然而，如果文件量很大，这样做就会消耗很长时间，并且波及到大量的对象存储数据复制。为了解决这个问题，JuiceFS 新增了 目录克隆 的性能，能够疾速复制指定目录下的所有文件。新复制进去的文件有本人的元数据，然而和原文件共享数据块，只是将其援用计数加一。克隆实现后，两边的文件都是独立的，能够各自批改而不会相互影响。因为克隆过程只波及到元数据操作，而不须要复制数据，因而速度会比一般的 cp 命令快很多。执行克隆的命令示例如下：
$ juicefs clone /mnt/jfs/dir1 /mnt/jfs/dir2一键复原回收站文件
JuiceFS 的回收站中，文件依照被删除的工夫归类，并且附加了原来父目录的索引号，用于在须要时找回其原来的地位。然而，在理论应用中，咱们发现利用这些信息从新构建目录构造比拟麻烦，只适宜手动复原大量的文件。为了解决这个问题，JuiceFS 在这个版本中新增了 juicefs restore 命令来帮忙整顿这些文件，例如：
$ juicefs restore redis://localhost/1 2023-05-10-01 --put-back以上命令能够将 .trash/2023-05-10-01 中的所有文件按其被删除时的目录构造放回原地位。如果原父目录不存在或者遇到有抵触的文件名，则会打印告警日志并跳过，用户后续能够再手动将其复原到想要的地位。
一键收集诊断信息
当 JuiceFS 在运行中呈现故障时，新接触的用户往往不晓得该如何剖析问题起因。因而，在这个版本中 JuiceFS 减少了 juicefs debug 命令来帮忙一键收集要害的现场信息，包含主机环境、软件版本和过程运行时状态等，如：
$ juicefs debug /mnt/jfs --out-dir /tmp/jfs-debug 待命令实现退出后，用户能够在 /tmp/jfs-debug 中找到一个以挂载点名称和工夫戳命名的 .zip 文件，外面即蕴含此次收集的诊断信息。
疾速查看用量统计
在生产环境中，管理员常常须要定期查看文件系统的使用量状况，或者找出以后零碎中最占用空间的目录等。在 JuiceFS 之前版本中，这须要管理员手动统计多个目录的用量（比方执行 du 命令），而后进行排序筛选，这样做既麻烦又可能耗时很长。为了解决这个问题，在这个版本中，JuiceFS 新增了 juicefs summary 命令来疾速查看指定目录下的用量统计。例如：
$ juicefs summary /mnt/jfs --depth 1 --entries 5
+------+---------+------+-------+
| PATH | SIZE | DIRS | FILES |
+------+---------+------+-------+
| / | 176 MiB | 9 | 20 |
| d2/ | 43 MiB | 1 | 5 |
| d4/ | 40 MiB | 3 | 4 |
| d5/ | 40 MiB | 1 | 4 |
| d3/ | 23 MiB | 1 | 4 |
| d1/ | 20 MiB | 1 | 2 |
| ... | 10 MiB | 1 | 1 |
+------+---------+------+-------+上述命令会统计 /mnt/jfs 下所有一级目录的使用量，并依据 SIZE 从大到小排序后显示最高的 5 项。
其余新性能
在这个版本中，JuiceFS 还减少了一些其余性能来进步零碎的安全性与易用性，包含：
- 在 mount 时通过
--root-squash选项来将 root 用户映射为一个非特权用户，以此来缩小权限安全隐患和避免误操作 - 在 mount 时通过
--enable-ioctl选项来使能对ioctl的局部反对，目前能用来设置一些非凡标记位来管制文件的行为，如append only (a)和immutable (i) - 在应用
juicefs sync工具时，新反对了jfs://前缀，能够在不挂载的状况下就间接将对象存储与 JuiceFS 内文件同步
新的元数据引擎
在此版本中，JuiceFS 还引入了一种新的元数据引擎 FoundationDB。这是一款由 Apple 公司开源的分布式数据库，可能在多个集群服务器上高效地存储和治理大规模的结构化数据。它具备高性能、高可扩展性和高容错性的特点。要应用 FoundationDB 作为 JuiceFS 的元数据引擎，只需将 Meta-URL 设置为：fdb://<cluster_file_path>?prefix=<prefix>。其中 cluster_file_path 是 FoundationDB 的配置文件门路，用于连贯其服务端。而 prefix 是一个用户自定义的字符串（与应用 TiKV 相似），能够在多个文件系统或者利用共用一个 FoundationDB 集群时，辨别不同的元数据空间。示例如下：
$ juicefs format \
--storage s3 \
... \
"fdb:///etc/foundationdb/fdb.cluster?prefix=jfs" \
pics具体应用细节能够参考文档
v1.1-Beta 下载地址：https://github.com/juicedata/juicefs/releases/tag/v1.1.0-beta1
心愿这些变动可能让你在应用 JuiceFS 时感到更加轻松、便捷和高效。咱们也期待你提供贵重的反馈和意见。如果你还没有开始应用 JuiceFS，能够关注咱们的公众号，或者拜访官网，咱们为开发者筹备了具体的文档和博客。
