什么是 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 分钟时间才会生效。有兴趣的同学可查看相关代码。
