-
Notifications
You must be signed in to change notification settings - Fork 212
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
Genesis import fails for large exports #9567
Labels
Comments
mergify bot
added a commit
that referenced
this issue
Jun 25, 2024
Closes #9567 ## Description Stores the swing-store export data outside of the genesis file, and only include a hash of it in genesis for validation. This is the bulk of the data in the genesis file (on mainnet 6GB vs 300MB for the rest), and it serves little purpose to keep it in there. Furthermore golevelDB chokes when cosmos attempts to store the genesis file inside the DB (limit of 4GB documents) ### Security Considerations None, the data remains validated ### Scaling Considerations Reduces memory usage on genesis export / import. Furthermore we avoid iterating over the data twice on import, which is painfully slow for IAVL. ### Documentation Considerations None ### Testing Considerations Added a3p acceptance test Manually tested as follow: ``` cd packages/cosmic-swingset make scenario2-setup make scenario2-run-chain # wait until there are blocks, then kill mkdir t1/n0/export agd --home t1/n0 export --export-dir t1/n0/export agd --home t1/n0 tendermint unsafe-reset-all mv t1/n0/export/* t1/n0/config make scenario2-run-chain # verify blocks are being produced after genesis restart ``` ### Upgrade Considerations There is a compatibility mode to load genesis files with export data embedded.
mhofman
pushed a commit
that referenced
this issue
Jun 25, 2024
Closes #9567 ## Description Stores the swing-store export data outside of the genesis file, and only include a hash of it in genesis for validation. This is the bulk of the data in the genesis file (on mainnet 6GB vs 300MB for the rest), and it serves little purpose to keep it in there. Furthermore golevelDB chokes when cosmos attempts to store the genesis file inside the DB (limit of 4GB documents) ### Security Considerations None, the data remains validated ### Scaling Considerations Reduces memory usage on genesis export / import. Furthermore we avoid iterating over the data twice on import, which is painfully slow for IAVL. ### Documentation Considerations None ### Testing Considerations Added a3p acceptance test Manually tested as follow: ``` cd packages/cosmic-swingset make scenario2-setup make scenario2-run-chain # wait until there are blocks, then kill mkdir t1/n0/export agd --home t1/n0 export --export-dir t1/n0/export agd --home t1/n0 tendermint unsafe-reset-all mv t1/n0/export/* t1/n0/config make scenario2-run-chain # verify blocks are being produced after genesis restart ``` ### Upgrade Considerations There is a compatibility mode to load genesis files with export data embedded.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Generating a new genesis through
agd export
results in agenesis.json
that is too large to be imported. Besides the large amount of memory used, the cosmos sdk attempts to store the original genesis file as is in its golevelDB, which has a limit of 4GB per document.To Reproduce
agd export
on mainnet or devnet, followed byagd start
using the new genesisExpected behavior
While large genesis can result in a huge RAM consumption, it should at least be possible to import.
Platform Environment
upgrade-15 and master on mainnet or devnet
Screenshots
The text was updated successfully, but these errors were encountered: