元数据一致性和对象存储回收清理的时机的问题

[frostwind]

文档中提到redis可以使用Everysec选项换取一定程度的性能提升，代价是会损失最后几秒钟写入的数据。与此类似的还有MySQL的innodb_flush_log_at_trx_commit和PostgreSQL的synchronous_commit, 但文档中对MySQL和PG没有说明这两个参数的影响。比方说我用PostgreSQL的synchronous_commit=OFF，pgbench读写混合负载可以到80K TPS,如果synchronous_commit=ON, pgbench只能到10K左右TPS。synchronous_commit=OFF的代价是，会损失大约0.6sec的最后写入的数据，但DB本身还是一致的，这样可以极大提升写入密集场景的元数据服务能力。
那么synchronous_commit=OFF，和innodb_flush_log_at_trx_commit=0/2这种设置，对于juicefs来说，可以保证元数据和对象存储之间的一致性吗？
比方说我修改一个文件之后写一个新块到对象存储，之后更新元数据DB，但是元数据DB在WAL log flush持久化之前crash了，元数据DB再起来之后反映的还是文件的老的状态，写入对象存储的新块没有成为文件的一部分，他成为orphan object等待被回收。这个场景看起来是可以保证一致性的。
还是考虑上面的同样场景，唯一不同的是，在时间点1，更新元数据DB之后，和时间点2，元数据DB在WAL log flush持久化之前，有一个没启用“--no-bgjob"的client插进来了，开始回收删除没有引用的对象 , 他删除完一些没引用的对象之后，元数据DB crash了，然后元数据DB又启动了，这时候元数据DB还是以前的版本，但是他需要的对象存储的数据已经被回收删除了，这样元数据DB和对象存储就不一致了。
我自己单个挂载点(with “--no-bgjob")测试fio random 4k write的时候，能看到很多 select count(*) from jfs_chunk_ref where refs=0的数据然后从几万很快下降到0，感觉这个清理没引用的对象存储的速度非常的快，想请教一下做后台清理的client触发清理的时机是怎么样的？如果能够有办法配置让这个清除没引用的对象存储的job有一定的延时去清理，就可以允许我们配置元数据DB的synchronous_commit=OFF或者innodb_flush_log_at_trx_commit=0/2，对应到PG大约是0.6 sec（三倍的wal_writer_delay）, MySQL 大约是1 sec的，比方说我们允许延迟清理5 sec或者10sec就足够了。

[frostwind]

cc @anysql

[anysql]

Redis的EverySec、pg的synchronous_commit、MySQL的innodb_flush_log_at_trx_commit，这些设置是元数据服务方的设置，由于我们支持很多种元数据选择，因此对各种元数据的具体配置并没有展开文档讨论。这里假定很多用户，会有相应的内部Redis/Postgre SQL/MySQL运维人员或外部专家支持。

如果性能比较重要，synchronous_commit=OFF，和innodb_flush_log_at_trx_commit=0/2这种设置基本上是可以的。juicefs和对象存储之间是两个离得比较远的系统，上传和删除都是用最终一致性技术来解决的。如果元数据和对象存储不一致，还有gc/fsck等命令可以发现和消除不一致的现象，清除对象存储上多余的部份，这个可以看一下相关文档。

no-bgjob的客户端会去清理jfs_chunk_ref这个问题，我们会去看一下，可能这个客户端不去做删除操作会更好。

有些元数据是纯内存的，所以在设计存贮格式时比较紧凑，在jfs_chunk_ref中没有储refs变成0的时间字段，因此delay一段时间从本质上是无法实现的。如果要保留jfs_chunk_ref信息一段时间，象pg/mysql可以搭建有一定时延的只读备份，这个相关领域的专业人员比较了解。

[SandyXSD]

可以启用回收站来规避此类不一致问题。