扩展订单填充策略

[dtynn]

可以考虑的方向：

• 允许 sealing_thread 等待订单，直到满足条件
• 允许设定最小填充Piece量/数据量

[ly82505129]

是否可以设置为等待多久的数据量，理论来说等待一段时间就应该可以开始处理deal了，正常来说看起来是连续的deal

[dtynn]

是否可以设置为等待多久的数据量，理论来说等待一段时间就应该可以开始处理deal了，正常来说看起来是连续的deal

嗯，这是一种常见的策略，实现起来也不复杂。
但是，可能还包含一些额外的决策，比如：

• 如果等不到订单，是开启 CC 流程，还是如何
• 如果等到的数据量不足（考虑成本，很有可能未来会存在成本平衡线，比如一个扇区内存储多大的有效数据量才不亏），如何决策

这个issue 会是一个较长期的讨论，你有什么想法随时可以提到这边 @ly82505129

[ly82505129]

正常一个扇区理论来说肯定存储满足32G的Datacap比较合理，但是往往有时候没办法凑的特别刚好，所以在一定周期内尽可能大，如果在5个小时之内只有18G那也要开始封装了

[dtynn]

正常一个扇区理论来说肯定存储满足32G的Datacap比较合理，但是往往有时候没办法凑的特别刚好，所以在一定周期内尽可能大，如果在5个小时之内只有18G那也要开始封装了

没错，这个也是现在 lotus 的算力组件体系中的策略。
我们还想看看有没有其他的策略，比如类似 必须首先满足80%的填充率，接下来 1) 继续等待30min; 2) 达成90%填充率; 任一条件达成立即启动

[ly82505129]

正常一个扇区理论来说肯定存储满足32G的Datacap比较合理，但是往往有时候没办法凑的特别刚好，所以在一定周期内尽可能大，如果在5个小时之内只有18G那也要开始封装了

没错，这个也是现在 lotus 的算力组件体系中的策略。 我们还想看看有没有其他的策略，比如类似 必须首先满足80%的填充率，接下来 1) 继续等待30min; 2) 达成90%填充率; 任一条件达成立即启动

看起来是个不错的策略

[dtynn]

related prs
filecoin-project/venus#4885
ipfs-force-community/droplet#132