Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[TieredStorage] Have HotStorageWriter::write_account() return Vec<StoredAccountInfo> #34929
[TieredStorage] Have HotStorageWriter::write_account() return Vec<StoredAccountInfo> #34929
Changes from 1 commit
7155992
97019c5
5dbd578
b4e3acf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah... very interesting...
We may want to tweak this API. It currently assumes that the total appended size is the same as summing up all the accounts appended. For Tiered Storage that's not the case.
Since we know all the accounts, and once we write then there will be no other writes, it means we know the total/final/complete size of the storage file. It'd probably be best to have this function return a tuple: a list of the stored account offsets, and a total size stored.
That would still work with AppendVec, and then would correctly set the size for Tiered Storage.
Since the size of the file in
AccountStorageEntry::alive_bytes
is used byshrink
, I think we want to ensure we accurately compute the size here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I think there should exist a better API. But if I remember it correctly, an estimation won't make accounts-db panic based on my previous run joining pop-net and main-net a while back.
I think the size of each entry is used to estimate the saving of a shrink when selecting which file / account to shrink in accounts-db. So I think it does want the information for each individual account, but no need to be super accurate.
If I remember it correctly, accounts-db won't panic when hot-storage only provide an estimation based on my previous run on mainnet / popnet with the hot storage (a while back).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should fix the API first, and then return the correct size here. IIRC the current append vec code uses the size when shrinking/reclaiming and creating new append vecs, and I believe there are new assumptions about having zero extra size in the append vec files. This was not always the case.
Option (2) would be to use this PR as-is, and create a GH issue to address fixing the API and updating this function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Let's do option 2. Will create an issue as a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just double-checked the accounts_db code.
When removing an account in AccountStorageEntry, it will maintain the
alive_bytes
by subtracting the stored_size. In that case, I think it's safer to not include the owner here in TieredStorage otherwise the alive_bytes will go negative.Will update the PR to use an estimate that will no larger than the actual stored size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the PR to consider only stored size directly contributed by the account (i.e., mainly account meta, data, and address).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for the API, the stored size of each account is still used when computing the estimated storage size saving when shrinking a specific accounts file (or append-vec). So I think the API should be good for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue created: #35041