什么是 JuiceFS Office Hours?
JuiceFS Office Hours 是每周三 17:00-18:00 的线上交流活动,主要目的是通过每周一次线上交流的形式,介绍和演示 JuiceFS 的新特性、解答用户疑问、了解使用场景及相关技术交流等。
要怎么参加 JuiceFS Office Hours?
请在每周三 17:00 左右点击这个链接:https://meeting.tencent.com/dm/nVMnpAWkaFgu
哪里能看到历史收集的问题和回答?
历史收集的问题和回答会定期更新到 JuiceFS 官方博客,请订阅官方博客了解最新动态。
能详细介绍一下 JuiceFS CSI Driver 0.10.0 以后的新架构和新特性吗?
JuiceFS CSI Driver 自 0.10.0 开始对架构设计做了比较大的升级,主要改动是将原本运行在 CSI Node 容器中的 JuiceFS 挂载进程独立出来,用单独的 pod 来运行。这次架构升级的主要目的一方面是增强系统的稳定性和可观测性,另一方面是提供平滑升级 CSI Driver 的能力。有关 0.10 全新架构的解读可以查看官方博客。
0.10.0 发布以后发现了一些比较关键的 bug,因此又陆续发布了多个 bug 修复版本。此外在近期发布的 0.10.5 中还新增了对 ReadOnlyMany
的支持,可以支持只读模式挂载。
func (s *sliceReader) run()
在这个函数实现中大量的 lock 和 unlock 逻辑能加上注释或者有专门的文章讲解一下吗?
这块逻辑的确比较复杂,后续我们计划用专门的文章进行代码讲解(不仅限于这一个函数)。
如果负责 mount 的 pod 异常挂掉,会影响到业务吗?影响范围?解决方案?
会,会影响到挂掉的 node 上使用该 PV 的所有 pod。解决方案只能删除 pod,重建 pod。
JuiceFS CSI Driver 如何平滑升级?
如果只升级 JuiceFS CSI Driver,已经存在的 PV 不会受到影响,还可以继续使用旧版本的 JuiceFS 客户端,新的 PV 会使用新版本的 JuiceFS 客户端;如果需要升级 JuiceFS 客户端,必须删除所有 pod 及 PV,重新创建 PV 和 pod。
Redis 作为元数据引擎是如何保证数据持久化的?
关于 Redis 如何保证数据持久化在「Redis 最佳实践」文档中有详细描述。简单讲 Redis 默认是通过 1 秒落盘一次 AOF 以及定期 dump RDB 来实现,因此极端情况可能会丢失最近 1 秒的数据。但是 Redis 支持把 AOF 落盘频率改成每次写入时同步持久化,不过这个配置更改会对写入性能有一定负面影响。
如果你想了解不同 Redis AOF 配置的性能对比,请参考「元数据引擎性能对比测试」文档。
JuiceFS 客户端是否有文件数据块的缓存(类似 page cache)?如果有大小是可配置的吗?
有,且缓存大小可配置。关于 JuiceFS 客户端缓存功能的详细介绍请参考「缓存管理」文档。
如果想要测试 JuiceFS 商业版元数据引擎的高可用,请问有什么测试建议?
JuiceFS 商业版元数据引擎是 Juicedata 团队基于 Raft 自研的分布式存储引擎,在默认 3 节点的集群配置下,允许任意 1 个节点宕机。因此如果要测试高可用可以通过随机宕机 1 个节点,并观察集群状态、自动恢复周期、对应用的影响等指标。
有考虑过实现数据存储服务,而不是使用 S3 作为后端存储?实现难点是什么?
暂时没有计划实现一个独立的数据存储服务,对象存储作为公有云上的一个标准基础设施应用已经非常广泛,暂时没有必要重复造轮子。
JuiceFS 有 Slack 的 workspace 么?现在的社区主要有哪些的 channel?
JuiceFS 有官方的 Slack workspace,可以点击这里加入。在 JuiceFS 的 GitHub 首页以及 JuiceFS 官网也都有加入 Slack 的入口。
目前 Slack 频道交流以英文为主,也有一个专门针对中文用户的 #chinese-users
频道。
CSI node driver 升级不影响 mount pod,如果 mount pod 升级的话,是否应用 pod 需要停止访问?这方面有哪些优化思路?
是的,如果要升级 mount pod 必须将当前节点所有使用对应 PV 的 pod 停掉。
一种优化思路是把 container 里 volumeMounts
的 mountPropagation
设置成 Bidirectional
,这样如果 mount pod 挂了,只要能重建挂载点 pod,上层的业务 pod 就不受影响。但是这个方法有一个很大的限制,业务 pod 必须设置 Privileged
为 true,相当于获得了 root 权限。
另一种优化思路是当 mount pod 退出时,保存 FUSE 层的一些状态,这样当 mount pod 重建以后再恢复之前的状态。这个方案相对复杂,目前还没有成熟的参考对象。
2021.11.17 更新:JuiceFS CSI Driver v0.10.7 已经支持第一种方案,详情请参考文档。
JuiceFS + S3/Ceph 的模式在大数据场景下,与原生的 HDFS 相比,性能如何?
在基于 TPC-DS 的评测中,当有缓存的情况下,JuiceFS 可以做到与 HDFS 性能相当。同时 JuiceFS 也能提供和 HDFS 类似的数据本地性(data locality)特性,确保缓存数据的命中率。
JuiceFS FUSE 接口和 native 接口的性能差异有 benchmark 吗?
暂时没有做过这类测试。从经验上来说,FUSE 接口的性能开销在整体读写链路上的耗时占比比较小,对象存储会首先成为瓶颈。
测试 warmup(版本 0.17.0)时发现一个现象,当 warmup 指定为目录时耗时较少,而通过脚本遍历目录中的文件依次执行 warmup 时,耗时会明显变多。请问可能是什么原因造成的?以及有没有办法加快 warmup 的速度?
当 warmup
的参数为目录时的实现是将需要预热的目录发送给 JuiceFS 挂载点,JuiceFS 挂载点会遍历整个目录再并行预热缓存(并行度可通过 --threads
选项控制,默认为 50)。而自行遍历目录,每次执行 warmup
时只指定单个文件就没法并行处理,自然效率会降低不少。
建议运行 warmup
时直接指定需要预热的目录,或者如果不想整个预热目录里的所有文件也可以通过 --file
选项指定需要预热的文件列表(一行一个文件路径)。预热的并行度可通过 --threads
选项控制。默认预热是前台执行,即 warmup
命令会等待全部文件预热完成才会返回,如果不想等待可加上 --background
选项。
更新容量后,mount 点数据未更新是什么原因?
通过 juicefs format --capacity
更新容量以后立即执行 df
不一定能马上看到更新后的值,需要等待最多 1 分钟时间才会生效。有兴趣的同学可查看相关代码。