parallel replicas info read from disk for deadlines containing ten thousands of sectors

[mslovy]

Checklist

• This is not a new feature or an enhancement to the Filecoin protocol. If it is, please open an FIP issue.
• This is not a new feature request. If it is, please file a feature request instead.
• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
• I have a specific, actionable, and well motivated improvement to propose.

Lotus component

• lotus daemon - chain sync
• lotus miner - mining and block production
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt)
• lotus miner/market - storage deal
• lotus miner/market - retrieval deal
• lotus miner/market - data transfer
• lotus client
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Improvement Suggestion

Now, when doing windowpost, each sectors in the deadlines would like to read p_aux from disk and build its replicainfo in the code bellow:
[rust-filecoin-proofs-api](https://github.com/filecoin-project/rust-filecoin-proofs-api/blob/250963c69f13bef8ab91f709e9e33c9e1d760fbd/src/post.rs#L407)

There is no problem for a deadlines containing e.g. 2300 or 4600 sectors, but for ten thousands of sectors in one deadlines, loading replicainfo from disk cost too long for windowpost process. So we sugguest to parallel the process here and improve the performance for the windowpost.

filecoin-project/rust-filecoin-proofs-api#69 (comment)

[rjan90]

Hey @mslovy!

Thanks for the ticket. This issue should have been addressed in #8391 which allows to read the challenges in parallel, it is currently in the v1.15.2-release candidates.

I also reccommend that you check out setting up multiple PoSt-workers when you have ten thousands of sectors in one deadlines. That feature is also in v1.15.2, which will be cut as a stable release very soon. You can read the docs for it here: https://lotus.filecoin.io/storage-providers/seal-workers/post-workers/.

You can also play around with how many challenges you would like to read in parallel with this when running PoSt-workers:
--post-parallel-reads value maximum number of parallel challenge reads (0 = no limit) (default: 128)