Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: redeclare storage when unsealed state is checked #1377

Merged
merged 4 commits into from
Apr 17, 2023

Conversation

jacobheun
Copy link
Contributor

@jacobheun jacobheun commented Apr 15, 2023

Summary

Adds to #1191 to call storage redeclare on the lotus-miner. Lotus doesn't currently automatically detect fs changes, so this is needed to ensure we're able to automatically keep indexes and their metadata up to date.

Speaking with the Lotus team, this call should be cheap so running it regularly shouldn't be an issue.

Screenshot from devnet

This is a screenshot of the before and after lotus-miner storage list. On the left the list shows 2 of 4 sectors as being unsealed, but we can see by the screenshot that there is only 1 unsealed sector. After the logs of the job execute (on the right), the storage list then correctly shows 1 of 4 sectors as unsealed.

Screenshot 2023-04-15 at 1 48 27 PM

Note on Frequency of this check

It may be useful to allow configuring how often the unseal manager is run. Currently it runs every hour, but in reality it doesn't need to run that frequently. 12 or even 24h is likely a more reasonable default as we ultimately just care about eventual consistency and hour to hour changes aren't likely to be very frequent.

Edit: I set this to 12 hours for now, instead of the current 1 hour.

Remaining Work

  • Add configuration so that SP's can disable this in case they want to control when redeclares occur (default to enabled)

This is currently needed as lotus doesnt automatically update when the fs changes
*Update default duration to 12hours from 1hour

*Allow users to disabl redeclaration of storage

chore: make gen
@jacobheun jacobheun force-pushed the feat/storage-redeclare-job branch from e0ae2f2 to 487a90a Compare April 15, 2023 19:51
@jacobheun jacobheun marked this pull request as ready for review April 15, 2023 19:55
@jacobheun jacobheun requested a review from dirkmc April 15, 2023 19:56
Copy link
Contributor

@dirkmc dirkmc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great 👐

If it's cheap to run we might as well run it frequently, I'd say once per hour is a good cadence.

@jacobheun
Copy link
Contributor Author

Moved this back to the original hour as default.

@jacobheun jacobheun merged commit 5ee625a into feat/update-idx-unseal Apr 17, 2023
@jacobheun jacobheun deleted the feat/storage-redeclare-job branch April 17, 2023 09:53
jacobheun added a commit that referenced this pull request Apr 17, 2023
* feat: monitor sectors unsealed state

* feat: announce deals to indexer as newly unsealed or no longer unsealed

* feat: test for unsealed state manager

* feat: update metadata if seal state changes, call NotifyRemove if sector is removed

* feat: better logging

* feat: check sector seal state once per hour

* feat: act on all deals in a sector

* feat: announce sealing state changes for legacy deals also

* fix: gfm type

* chore: fix merge miss

* feat: redeclare storage when unsealed state is checked (#1377)

* feat: redeclare storage when unsealed state is checked

This is currently needed as lotus doesnt automatically update when the fs changes

* chore: fix linting

* feat: make unsealedstatemanager configurable

*Update default duration to 12hours from 1hour

*Allow users to disabl redeclaration of storage

chore: make gen

* refactor: move storage list to 1hour interval

---------

Co-authored-by: Jacob Heun <[email protected]>
Co-authored-by: Jacob Heun <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants