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

[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