能否讲讲 JuiceFS 在大数据场景下的优势及特点，以及与其他友商产品对比分析，如阿里的 JindoFS 之类的。
JuiceFS 的优势：
- 完全兼容 HDFS API，Hadoop 生态组件无缝适配。
- 相比 HDFS：容量弹性伸缩；存储计算分离，计算资源可以灵活配置和伸缩；相比云上用云盘自建 HDFS，成本节省超过 60%，同时能提供与 HDFS 相当的读写性能；支持 POSIX、S3 接口，用一个存储适配不同业务的访问需求；JuiceFS 商业版提供全托管 SaaS 服务，零运维，且能在单一命令空间里支持百亿级的文件存储。
- 相比对象存储：完整文件系统语义，大数据生态组件适配性好；强一致性；10 倍以上的元数据操作（list、rename 等）性能提升，综合读写性能也能提升数倍；支持 POSIX 接口。
JindoFS 的 block 模式更加类似 JuiceFS（缓存模式类似 Alluxio），具体性能对比可以参考我们之前的一篇博客：/zh-cn/blog/cache-system-of-hadoop-comparison
JuiceFS 现在的性能瓶颈是在哪里？最好的性能可以达到多少？
对于常见场景，性能瓶颈主要在访问对象存储的延时和吞吐，元数据引擎如果用 Redis 性能已经足够好，用 SQL 数据库的话会有一定性能损失（参考元数据引擎 benchmark）。
对于超大规模场景，FUSE 本身带来的开销也不容小觑。
最好的性能：元数据如果用 Redis 延时可以到微秒级，IOPS 可以到 5000+；单机并发顺序读吞吐能接近 3000MiB/s，结合缓存性能可以进一步提升。参考性能测试文档。
请问 JuiceFS Windows 客户端的稳定性如何？
JuiceFS Windows 客户端依赖 WinFsp 这个第三方组件，目前这个方案已经在 JuiceFS 社区版和托管服务中稳定使用多年。关于如何在 Windows 上使用 JuiceFS 请参考文档。
如果把 JuiceFS 开源版本集成到商业产品中会有版权和法律问题吗，或者需要注意什么？
如果不是直接进行代码集成或者二次开发，仅仅作为一个内部组件使用，不直接分发给用户（包括网络分发），不会有版权和法律问题。如果有这部分需求可以联系我们申请单独的商业 license。
JuiceFS 是否可以实现跨数据中心部署方案（比如两地三中心金融级业务部署）？私有云部署推荐的对象存储是哪款？
可以实现跨数据中心部署方案，不过有几个注意事项：
- 元数据引擎（如 Redis）需要支持跨数据中心同步。同时需要注意跨数据中心访问元数据的延时问题，如果数据是只读的可以考虑从当前数据中心的元数据引擎获取。
- 对象存储需要支持跨数据中心同步
私有云部署的对象存储有多种方案可以选择，比如 Ceph、Swift、MinIO 等，它们适应的场景和规模各有不同，可以分别测试评估验证是否能够满足您的需要。此外还有很多支持私有化部署的商业存储（如金山云、七牛云、杉岩等）。
目前 Prometheus 监控方案的数据具体是如何从客户端拉取的？是客户端主动上报还是怎么样？
JuiceFS 文件系统挂载好以后会监听一个用于获取 Prometheus 监控指标的端口（默认端口号是 9567，可以通过 --metrics 选项修改），需要配置 Prometheus 主动从这个地址拉取监控指标。如果你是在 Kubernetes 上使用 JuiceFS，可以参考这个文档配置 Prometheus。
如果你使用的是 JuiceFS Hadoop Java SDK，需要通过相关配置主动上报监控指标到 Pushgateway，详细步骤请参考这个文档。
Attr 结构体中，Mode 字段低 9 位应该是表示本用户/本用户组/其他用户组的读/写/执行权限的，那高位表示什么呢？下面的代码中对 mode 的操作是什么意思？
低 12 位是权限，其中低 9 位是 owner/group/other 权限，其他 3 位是 sticky bit、SUID 和 SGID，高位保留。上面的代码就是在当用户修改 owner/group 时，要去掉 SUID 和 SGID（出于安全考虑）。
重命名一个文件时 JuiceFS 只对文件进行加锁，但其它一些文件系统（如 BFS、CephFS）是会对所有父目录加读锁，这是为什么？
因为 JuiceFS 的元数据 API 是基于 inode 的，当原路径和目标路径的 inode 确定时，即可以完成 rename 操作，而不用担心别人是否会同时对这两个目录做 rename 操作。
JuiceFS 目前没有实现 forget 语义，如果删除某个 inode，但内核中的 lookup count 还不为 0，这个会有什么影响吗？
JuiceFS 的 inode 是 64 位的自增 ID，inode 一旦分配就不会复用，因此也不存在需要主动 forget 的问题。
Readdir 这个操作，目前会将所有的 entry 读到客户端缓存起来，供后续使用。如果 entry 项过多，可能会对内存有较大压力，这块会有问题吗？
会有压力，但是压力是可接受的。例如按单个 entry 占用 100 字节估算，1 千万个 entry 需要约 950MiB 内存，是可以存得下的。当然很多时候不推荐单目录存放太多 entry，这会对应用造成负面影响（比如 ls 卡住）。
Redis 作为元数据引擎时会占用多大内存？
Redis 的内存占用与文件系统中存储的文件数量关联，我们的经验值是 1 个文件大约占用 300 字节内存。因此如果存储 1 亿个文件，大约需要 30GB 内存。详情参考 Redis 最佳实践。
Redis 应该不能保证不丢数据吧？
默认情况下 AOF 持久化到磁盘的时间周期是 1 秒，因此最坏情况下会丢失最近 1 秒的数据。不过可以调整 Redis 的配置将 AOF 改成每次执行命令都同步持久化到磁盘，但这会带来一定的性能损耗。如果你想了解不同 Redis AOF 配置的性能对比，请参考「元数据引擎性能对比测试」文档。
Redis 故障切换的时候有可能会造成少量数据丢失，因为 Redis 的主从同步是异步的，因此当通过 Redis Sentinel 进行自动故障切换时不保证数据已经完全从 master 同步到 slave。关于这一点在 Redis 官方文档中也有说明。
建议阅读「Redis 最佳实践」文档。
TiKV 作为元数据引擎对比 MySQL 会有性能提升吗？
TiKV 相比 MySQL 在某些元数据操作上会有性能提升，比如 mkdir、mvdir、write，但某些操作会慢一些。总体来说两者性能相当。
详细对比数据请参考「元数据引擎性能对比测试」。
JuiceFS 允许多个 mount 用户同时修改同一个文件吗？如果可以，文件内容最终以谁为准呢？
JuiceFS 允许多客户端同时修改一个文件，每个客户端的写都是原子的，最新的写操作会覆盖前面的。可以通过锁来保证写入顺序，目前 JuiceFS 支持 BSD 锁（flock）和 POSIX 记录锁（fcntl）。
fcntl 的具体实现在 pkg/meta/<XXX>_lock.go 文件，如 Redis 引擎对应的是 pkg/meta/redis_lock.go。文件中的 Getlk() 和 Setlk() 函数即为 fcntl 文件锁的具体实现。
有测试过 SQLite 的性能吗？
没有。因为 SQLite 通常并不适用于生产环境，所以当前的「元数据引擎性能对比测试」不包含 SQLite。有兴趣的同学可以参考文档中列举的测试命令自行测试。
JuiceFS 对存储的优化、对元数据管理的创新等等这些优化操作，会不会被底层存储吸收借鉴？这样 JuiceFS 竞争力就有所下降？或者说哪点是只有 JuiceFS 适合做而不适合底层存储做的工作那？
一部分优化可能会被底层存储借鉴，例如对象存储近几年也在尝试优化如一致性、rename 性能等问题。但是 JuiceFS 以一种新颖的架构设计解决了更多传统云上文件存储面临的问题，底层存储想要彻底解决这些问题势必需要对架构进行大的升级改造，因此我们也看到类似阿里云 JindoFS、腾讯云 GooseFS 这样的产品出现。
JuiceFS 与 S3FS 的差别是什么？
JuiceFS 完全兼容 POSIX，除此之外还提供诸如 mmap、fallocate、扩展属性、文件锁等高级特性。在性能评测中，JuiceFS 相比 S3FS 也有着几十倍，甚至上百倍的性能提升。
抛开性能，在大数据场景下，JuiceFS 和 Alluxio 的区别在哪？
简单来说 JuiceFS 与 Alluxio 在存储格式、缓存粒度、POSIX 兼容性、原子元数据操作、一致性、运维复杂度这些方面都有很大区别，具体可以参考这篇文档。
如果关注大数据场景下的性能比较，可以参考我们之前的一篇博客。
有考虑过实现数据存储服务，而不是使用 S3 作为后端存储？实现难点是什么？
暂时没有计划实现一个独立的数据存储服务，对象存储作为公有云上的一个标准基础设施应用已经非常广泛，暂时没有必要重复造轮子。
JuiceFS + S3/Ceph 的模式在大数据场景下，与原生的 HDFS 相比，性能如何？
在基于 TPC-DS 的评测中，当有缓存的情况下，JuiceFS 可以做到与 HDFS 性能相当。同时 JuiceFS 也能提供和 HDFS 类似的数据本地性（data locality）特性，确保缓存数据的命中率。
如果想要测试 JuiceFS 商业版元数据引擎的高可用，请问有什么测试建议？
JuiceFS 商业版元数据引擎是 Juicedata 团队基于 Raft 自研的分布式存储引擎，在默认 3 节点的集群配置下，允许任意 1 个节点宕机。因此如果要测试高可用可以通过随机宕机 1 个节点，并观察集群状态、自动恢复周期、对应用的影响等指标。
