咱们很快乐地发表 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,能够关注咱们的公众号,或者拜访官网,咱们为开发者筹备了具体的文档和博客。