Skip to content
This repository has been archived by the owner on Jun 6, 2023. It is now read-only.

Optimize RescheduleAllAsFaults #1413

Open
Stebalien opened this issue May 13, 2021 · 2 comments
Open

Optimize RescheduleAllAsFaults #1413

Stebalien opened this issue May 13, 2021 · 2 comments
Labels
change-behaviour Changes behaviour or state interpretation, necessitating a network version upgrade enhancement New feature or request scale Related to chain state or throughput scalability
Milestone

Comments

@Stebalien
Copy link
Member

It currently:

  1. Walks over all epochs after the new fault expiration epoch.
  2. Collects all sectors.
  3. Reschedules them to the fault expiration epoch.

Unfortunately, this will cause as many IPLD reads (from cron) as there are distinct sector expirations.

Instead, we should pass in the known faulty power, non-faulty power, faulty sectors, and non-faulty sectors. Then, we can subtract out the epochs we're not going to reschedule, schedule the new expiration for the remaining sectors, and batch delete the rest.

@Stebalien Stebalien added enhancement New feature or request scale Related to chain state or throughput scalability change-behaviour Changes behaviour or state interpretation, necessitating a network version upgrade labels May 13, 2021
@BigLep BigLep modified the milestones: v4, v5, Network Hyperdrive, v6 May 13, 2021
@BigLep
Copy link
Member

BigLep commented May 14, 2021

From @Stebalien on Slack: Assuming a 20s cron is "fine" in the extreme case where everyone starts missing storage, can reach a network capacity of 167EiB before it starts being a problem. That should put it out far enough such that we can we can punt on this for now (but not forever).

@Stebalien
Copy link
Member Author

I've done some more calculation and we'd want to fix this within 3 years.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
change-behaviour Changes behaviour or state interpretation, necessitating a network version upgrade enhancement New feature or request scale Related to chain state or throughput scalability
Projects
None yet
Development

No branches or pull requests

2 participants