-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
RemoteFSAccessor: Make the local NAR cache content-addressed #14948
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
Conversation
|
Do we need to bump a cache version? |
|
@Ericson2314 There is no version at the moment. There shouldn't be any upgrade issues since the new file names in the cache have a different length. |
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.
There is no version at the moment. There shouldn't be any upgrade issues since the new file names in the cache have a different length.
sounds good
OK generally looks good, but I would make it a double map (see final comment) so we don't end up opening multiple NAR accessors for the same NAR.
949d142 to
ab2f409
Compare
Use double-indirection for better NAR accessor caching Co-authored-by: John Ericson <[email protected]>
It was not pulling its weight. (Only used once, optional paths are confusing, we already have an `if` / branch fit-for-purpose.)
ab2f409 to
2af5792
Compare
Motivation
Previously, the local NAR cache was indexed by the store path hash. Making it content-addressed (i.e. indexed by NAR hash) provides some potential deduplication, but more importantly, makes it possible to substitute NARs from the local NAR cache with fewer trust issues (see DeterminateSystems#279).
Context
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.