| 6 Dec 2025 |
raitobezarius | In reply to @dont.wanna.tell:matrix.org I think they are, am I missing anything? https://github.com/NixOS/nixpkgs/pull/441897#discussion_r2343911652 ? | 14:08:11 |
Martin Häcker | ah; I should have marked that as resolved, he did agree that minimal churn (especially in high stakes code like this) is an equally valuable goal. | 14:16:49 |
Jassuko | In reply to @raitobezarius:matrix.org It's the metadata layer of the Nix store, the actual source of truth How is this handled currently? And how big of a deal is rebuilding said metadata if everything goes wrong?
I’m trying to figure out what are the a actual requirements for the consistency of this DB. In some cases it might make sense to provide fast ”happy path” usage in expense of having to do considerably more costly repair operation in case of total failure. | 14:34:15 |
aloisw | This database is extremely important, if things go wrong you can of course still access the store paths that were already there as files so the system is not immediately broken, but from the Lix perspective the entire store might as well be trash. | 14:35:23 |
Jassuko | In reply to @aloisw:julia0815.de I expect rollback journal to be disastrously slow with the Lix store database, as it does at least one fsync per commit. You can try out yourself with the use-sqlite-wal setting if you want. How many write operations are needed per a build or other store operations? Or do you need a write per some file in derivation? Or what exactly? | 14:35:48 |
aloisw | From what I gathered during my investigations it is roughly 1 write transaction per derivation. | 14:36:21 |
Jassuko | But that is practically nothing..? | 14:36:43 |
aloisw | Uh what? To the contrary it is quite a lot of transactions. The huge volume of tiny transactions is also why there is so much amplification, I think. | 14:37:31 |
Jassuko | Like… you are already writing a bunch of files for each derivation… having to do a SQLite write should be rather trivial in that scope? | 14:37:34 |
Jassuko | Or does it have some weird schema or indexes that are absurdly slow to update..? | 14:38:34 |