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

Unified mode for undumping gzip-ed or era1-ed encoded block dumps #2198

Merged
merged 1 commit into from
May 20, 2024

Conversation

mjfh
Copy link
Contributor

@mjfh mjfh commented May 20, 2024

ackn:
Built on Daniel's work

@mjfh mjfh merged commit de03889 into master May 20, 2024
27 checks passed
@mjfh mjfh deleted the provide-era1-reader-interface branch May 20, 2024 13:59
dir*: string # Database folder
blocks*: KeyedQueue[uint64,Era1File] # Era1 block on disk
byBlkNum*: SortedSet[uint64,Era1DbBlocks] # File access info
ranges*: IntervalSetRef[uint64,uint64] # Covered ranges
Copy link
Member

Choose a reason for hiding this comment

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

an era1 file is exactly 8192 blocks (except the lasts one), so this code is not needed - in fact, the era files do not need to be indexed at all on startup (this is very slow) - all that's needed is the list of roots in the accumulator used for verifying era1 consistency (see getAccumulator in fluffy code) - from there, the names of the files and the ranges of blocks contained can be computed) cc @daniellm

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, this implementation seems overly complex to me. When I was planning on implementing this, it looked like I could do so very similar as EraDB is implemented, but with usage of the Accumulator instead.

@arnetheduck
Copy link
Member

arnetheduck commented May 22, 2024

Somewhat unfortunate that the binaries were added to the main repo - we tend to keep large files out from the main repos to keep cloning times reasonable - instead, a git submodule with a dedicated large-files repo should have been used.
Now, the damage is done (they're part of the master history), so let's leave them there but..

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.

None yet

3 participants