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

State Storage - State #571

Open
wants to merge 2 commits into
base: resharding
Choose a base branch
from
Open

State Storage - State #571

wants to merge 2 commits into from

Conversation

staffik
Copy link

@staffik staffik commented Nov 5, 2024

No description provided.

@staffik staffik requested a review from a team as a code owner November 5, 2024 12:52
@staffik staffik requested review from wacban and shreyan-gupta and removed request for a team November 5, 2024 12:52
Copy link
Contributor

@wacban wacban 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 overall!

I think the implementation details can go into the reference implemention section. Can you add a more high level overview in specification and move the rest? Can you also mention what the naive / brute force approach would be and why it is not feasible?

Copy link
Contributor

@wacban wacban left a comment

Choose a reason for hiding this comment

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

Once we have a good design for the integration with cold storage let's also add a short description of how that will work.

neps/nep-0568.md Outdated
Comment on lines 131 to 135
Mappings in `ShardUIdMapping` persist as long as any descendant shard still references the ancestor shard’s data.
When no descendants rely on a particular ancestor shard, its mapping entry can be removed, allowing the ancestor’s data to be garbage collected.
If a full state sync is performed for a child shard (downloading and storing all its data independently),
the mapping to the ancestor shard can also be removed, as the child’s data is now directly stored under its own `ShardUId`.

Copy link
Contributor

Choose a reason for hiding this comment

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

The cleanup shouldn't depend on state sync. I think we should cleanup the mapping when the node stops tracking all children / descendant shards. Also can you mention that the mapping will be permanent on archival nodes?

@staffik staffik requested a review from wacban November 5, 2024 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: NEW
Development

Successfully merging this pull request may close these issues.

2 participants