 | Lix | 1101 Members |
| Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms | 293 Servers |
| Lix | 1101 Members |
| Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms | 293 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 Dec 2025 | ||
 aloisw | Yeah the WAL just grows so much faster than the database, even with large WAL sizes checkpointing takes quite long. | 19:01:35 |
| aloisw | Page size of 512, WAL size of 1 GiB (lower should also work, only increasing the fsync cost) and RESTART checkpointing looks quite nice with the synthetic test case. There are still stalls, but they are like 7 seconds after 2 minutes. | 19:30:36 |
| 6 Dec 2025 | ||
 Jassuko | Hmmm. The database itself should not be very big, right? What is the consistency requirement for it? I.e. do we really need to care if the system crashes mid-build somewhere as long as the final state or such gets committed properly? | 10:50:42 |
| Jassuko | So, do we a actually need WAL, or would it better to just use the restore based journaling? Or if the intermediate steps are not that important to keep as we can just run the builds again after a crash, we could just copy the whole database on tempfs and run the restore checkpointed mode on there where latency on additional file operations would be minimal. And after some things or the whole operation is done, only then copy the relevant state to the db store on disk? | 10:53:56 |
 K900 | SQLite can only do multiple concurrent readers in WAL mode | 11:28:30 |
 522 it/its ⛯ΘΔ | wait, really? i thought WAL provided one writer and multiple readers, as opposed to one writer or multiple readers | 11:41:46 |
| 522 it/its ⛯ΘΔ | that's what https://sqlite.org/wal.html implies | 11:42:10 |
 Martin Häcker | Hey, we had a discussion in the bugtracker about adding I was hoping there are some people here on the channel wo think this useful and would be willing to help? | 11:42:41 |
| 522 it/its ⛯ΘΔ | wal is in general faster though yeah | 11:43:17 |
 raitobezarius | In reply to @dont.wanna.tell:matrix.orgIf all comments are resolved, I will merge it for you :) | 12:10:49 |
| aloisw | 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. | 12:14:13 |
| aloisw | We're already running in NORMAL synchronous mode, which sacrifices durability (which is in most cases, including Lix, not a big deal). Turning it off completely can (on most stock filesystems) give you a corrupted database after unclean shutdown which is absolutely not what you want. | 12:16:03 |
| aloisw | Yes, this is correct. Rollback journal allows any number of readers but the writer needs exclusive access. | 12:16:40 |
| aloisw | raitobezarius could you test https://gerrit.lix.systems/c/lix/+/4712 in your real-world setting? Be advised that if you use the daemon, the change will also be needed there, and for whatever reason there may happen a weird deadlock during the generation switch (I need to debug that). | 12:37:02 |
| raitobezarius | will do! | 12:58:29 |
| Martin Häcker | I think they are, are you missing anyhting? | 13:57:18 |
| Martin Häcker | * | 13:57:43 |
| raitobezarius | In reply to @dont.wanna.tell:matrix.orghttps://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 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.deHow 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 |
| raitobezarius | FS writes doesn't have the same performance penalty as a SQLite writes | 14:38:52 |
| aloisw | It is not just one write, it is one write transaction where it adds the derivation and its references to the database, plus probably some index updates. And it does not appear "absurdly slow" in general, the problem is the extreme write amplification. | 14:39:58 |
| Jassuko | In reply to @raitobezarius:matrix.orgOn the contrary… properly used the SQLite can exceed the performance of writing same amount of small files to the plain FS… | 14:40:30 |