You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
SQLite generally does a good job of storing the store object "metadata" (ie everything except the file system object).
However, it's not entirely without issues:
btw I'm not convinced that 90% of the correctness and scaling problems with the gc process are sqlite. it's likely that nix is misusing transactions, causing the store db to get a broken state. the actual deletion isn't done by a thread pool; it needs to be. and several other related things.
but determining whether the database is the problem should be empirically done first before simply trying to switch it out one for one.
Is your feature request related to a problem? Please describe.
SQLite generally does a good job of storing the store object "metadata" (ie everything except the file system object).
However, it's not entirely without issues:
json-meta://
store #9551json-meta://
store #9551Possibly other issues (please link).
Relevant discussion
Describe the solution you'd like
A parameter for
nix store init
to select a store db backend. Default: sqlite.A store settings file, akin to the binary cache
nix-cache-info
, but obviously more general.E.g.
/nix/var/nix/store-settings.json
A field in that file, to indicate which store db backend is used.
A virtual class
StoreDatabase
, with implementation for sqlite.LocalStore
/LocalFSStore
only depend onStoreDatabase
.Describe alternatives you've considered
Additional context
Priorities
Add 👍 to issues you find important.
The text was updated successfully, but these errors were encountered: