-
Notifications
You must be signed in to change notification settings - Fork 20.4k
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
core/rawdb: use AncientRange when initializing leveldb from freezer #23612
Conversation
Some hands-on testing, initializing Using
First run with this PR, with an off-by-one error I unintentionally left in:
Second run, with off by one error fixed:
So, it seems to work (now), and goes from |
cb204e9
to
344b53e
Compare
344b53e
to
64ca976
Compare
Rebased, PTAL |
@rjl493456442 could you please take a look at this one? |
@rjl493456442 a gentle, very soft ping in your general direction... |
I have no idea why this was closed, I must have been tired and closed/deleted the wrong PR. PTAL |
Sorry, I didn't check the message at all. I will check it. |
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.
LGTM
…thereum#23612) * core/rawdb: utilize AncientRange when initiating from freezer * core/rawdb: remove debug sanity check
…thereum#23612) * core/rawdb: utilize AncientRange when initiating from freezer * core/rawdb: remove debug sanity check
When we restore from ancients, we go through them and write the
hash->number
mapping into leveldb. As of a while back, we now have a methods to read ancients sequentially a lot faster.This PR can most easily be tested by doing a
geth --goerli removedb
, and leave ancients intact. Then ageth --goerli --nodiscover --maxpeers 0
.The PR (in draft) contains a little self-validator, which shouldCRIT
if the contents is not correct.