共计 3371 个字符，预计需要花费 9 分钟才能阅读完成。
JuiceFS v1.0 beta3 在元数据引擎方面持续加强，新增 etcd 反对小于 200 万文件的应用场景，相比 Redis 能够提供更好的可用性和安全性。同时反对了 Amazon MemoryDB for Redis 和 Redis Cluster。至此，JuiceFS 反对的元数据引擎有：
- Redis：包含单机、Sentinel 和 Cluster 模式，适宜小于 1 亿文件，同时谋求高性能的场景。基于 AOF 的异步复制有大量数据失落的危险，Amazon MemoryDB for Redis 应用同步数据复制，数据安全性更高；
- 关系型数据库：包含 MySQL、MariaDB、PostgreSQL，适宜数据安全要求高，性能要求不高的场景；
- TiKV：适宜海量文件（1 亿以上），对性能与数据安全都有高要求的场景，但运维门槛比后面的计划高；
- etcd：适宜小于 200 万文件并且可用性与数据安全要求高的场景；
- 嵌入式数据库：包含 BadgerDB 和 SQLite，适宜不须要多机拜访的场景应用。
除了元数据引擎的降级，JuiceFS S3 网关也提供了多租户、权限设置等高级性能，同时反对了非 UTF-8 编码的文件名。
本次更新共有 22 位社区贡献者 参加奉献了 超过 240 次提交，感激每一位的付出，也欢送正在读文章的你参加到 JuiceFS 社区中来。
上面，来为你解读一下 JuiceFS v1.0 beta3 的具体变动。
新增 etcd 元数据引擎
etcd 是一个数据牢靠的分布式 KV 存储系统，在 Kubernetes 中宽泛应用，etcd 的数据批改会同步写到磁盘上，保障数据安全，通过 Raft 共识算法实现数据复制和故障切换，实现高可用。相比应用异步落盘和异步复制的 Redis 有更好的数据安全性和可用性。
但 etcd 可能撑持的数据规模比拟无限，从理论测试来看，小于 200 万文件时，是个不错的抉择。
应用办法与其余引擎相似，协定头为 etcd://，例如：
# 创立文件系统
$ juicefs format etcd://localhost:2379/myjfs jfs-etcd
# 挂载文件系统
$ juicefs mount -d etcd://localhost:2379/myjfs /mnt/jfs对于 etcd 的性能体现，请查看《元数据引擎性能测试文档》。
反对 Redis Cluster 和 Amazon MemoryDB for Redis
因为 JuiceFS 依赖数据库事务保证数据强一致性，而 Redis Cluster 采纳分片机制将数据扩散在不同的分片上，但不反对跨分区的事务，导致不能应用 Redis Cluster 作为 JuiceFS 的元数据引擎。
v1.0 beta3 通过应用固定前缀的形式让所有的数据都调配到繁多的 Redis 分区中，从而保障了 Redis 事务性能不受影响。这个办法不能充沛享受 Redis 集群的数据分片能力，但能够取得数据复制和选举方面的便当（相似于哨兵模式）。另外，这种前缀形式相似于单机模式的多库性能，有有限的扩大能力，实用于有很多小规模文件系统的场景。
AWS 最新公布的 MemoryDB for Redis 只提供集群模式，相比 ElastiCache 或者本人保护的 Redis，它的同步数据复制提供了更高的数据安全保障（但写入提早更高），实用于对数据的安全性要求十分高，写少读多的场景。因为所有元数据都会集中在单个分片中，举荐应用一个分区加一份复制的部署模式（相似于主从模式），后续通过更换为更大内存的节点形式来扩容。
碎片提早清理性能
JuiceFS 在读写文件时，如果该文件的数据碎片过多，就会主动触发碎片合并流程，将碎片聚合成大段数据并清理掉旧的碎片。
然而，在元数据迁徙、故障复原等场景中，用户可能须要应用旧版本的元数据备份，此时如果数据碎片已被清理，就会导致相干文件读取失败。
另外，当 Redis 失落大量元数据时，也可能因为局部文件应用了曾经被清理的碎片而损坏。
为了解决上述问题，在 v1.0 beta3 中退出了 碎片提早清理性能，对于开启了回收站的文件系统，碎片会被提早删除，超过设定的回收站工夫后才被主动清理，也能够用 gc 命令手动清理。
加强 Sync 命令
v1.0 beta3 进一步调整了 Sync 命令的性能，使其在用法上与大家熟知的 rsync 工具尽量保持一致，缩小上手老本。
调整了用于过滤文件列表的 --include 和 --exclude 的用法，跟 rsync 保持一致，容许指定多个过滤规定，依据它们在命令行中的程序和 Bash 通配符进行匹配，简直能够实现任意汇合的文件筛选须要，更具体的用法请参照 rsync 的文档。
Sync 命令默认会拷贝符号链接的指标文件，能够通过 --links 参数调整为拷贝符号链接自身。
另外，还加了一个 --limit 参数用于限度操作的文件个数，当设置为 1 时示意不进行递归遍历。
S3 网关性能降级
JuiceFS 的 S3 网关是基于 MinIO 的晚期版本实现的，并且裁剪了一些非必要的性能。新版本的 MinIO 改用了 AGPL 协定，不能被 JuiceFS 间接降级应用。
当初采取了反向集成的策略，在反对网关性能的最新版 MinIO 上集成 JuiceFS v1.0 beta3，整体基于 AGPL 协定开源，这样能够应用新版本的 MinIO 提供的多租户、权限设置等更多高级性能，详情请参考 S3 网关文档。
JuiceFS 依然内置了根底版的 S3 网关性能，而更残缺的版本请应用这个反向集成的版本，代码请见。
其它新性能
- 反对 TLS 加密连贯 TiKV 元数据引擎。
- 创立文件系统时，能够通过
--hash-prefix选项为数据写入对象存储时增加哈希前缀。很多对象存储有基于前缀的 QPS 限度或者零碎瓶颈，通过该个性能够绕过这类限度以取得更好的性能。留神，已有数据写入的旧文件系统无奈更改此选项。 - 挂载文件系统时，能够通过
--heartbeat选项设置客户端的心跳距离，这在一些关注故障切换工夫的场景下能发挥作用。留神，默认的心跳过期工夫已由 60s 调整为 12s。 - 数据存储减少 Oracle Object Storage 反对。
- Java SDK 反对上报监控指标到 Graphite 或者兼容的零碎。
- SQL 引擎反对非 UTF-8 编码的文件名，已有的文件系统须要降级客户端后再批改数据库的表构造。
其它变动
- 在新建文件系统时，会主动在数据存储中写入一个记录了 UUID 的占位对象，防止其余文件系统重复使用雷同的数据存储造成混同。
juicefs dump命令会自动隐藏对象存储的 secret key 避免透露敏感信息。- 改用加密模式存储对象存储拜访密钥，减小安全隐患；已有的文件系统可通过
juicefs config META-URL --encrypt-secret命令调整加密模式。留神，批改后旧版客户端将无奈挂载。 - 调整元数据默认备份机制，当文件数多于一百万时，须要用户显式指定备份周期。
- 在 Linux 下应用非 root 用户挂载时，将默认的缓存和日志目录改为此用户的家目录，防止因权限有余而失败。
- 改良了往 Redis 和 SQL 数据库导入大型目录（超过一百万文件）的能力。
- 为关系型数据库所有表构造减少主键，晋升日志复制性能，详情参考。
降级倡议
请在降级新版前留神评估以下几个变动：
会话治理格局调整
自 v1.0 beta3 开始，会话治理应用了新的格局，旧版本客户端通过 juicefs status 或者 juicefs destroy 无奈看到 v1.0 beta3 的会话，新版客户端能够看到所有会话。
SQL 表结构调整，反对非 UTF-8 编码文件名
为了更好地反对非 UTF-8 编码的文件名，在 JuiceFS v1.0 beta3 中批改了关系型数据库的表构造。
对于正在应用 MySQL、MariaDB、PostgreSQL 的用户，如果须要让已有的文件系统反对非 UTF-8 编码的文件名，须要手动批改表构造，详情请参考文档。
修复的 Bug
- 修复了元数据备份失败时可能导致局部内存未及时开释问题。
- 修复了应用 SQL 作为元数据引擎时，扫描函数返回后果可能不正确问题。
- 修复了应用
juicefs load命令加载元数据时局部计数器可能统计不精确问题。 - 修复了对象存储开启多 buckets 时，扫描对象列表后果不正确问题。
- 修复了应用 Ceph RADOS 做对象存储时，对象数过多时扫描卡住问题。
具体的 Bug 修复列表请看 https://github.com/juicedata/…
快去下载体验吧，Juicedata/JuiceFS
