Lix should disallow auto-optimise-store on darwin for now #477

Open
opened 2024-08-20 09:14:36 +00:00 by weethet · 4 comments

Right now, to my knowledge, auto-optimise-store causes nix-store corruption on darwin systems. Until it is fixed, lix should not allow users to turn it on darwin.

Describe the solution you'd like

Any error when auto-optimise-store is enabled on darwin would be nice

Describe alternatives you've considered

Investigate and fix the underlying issue that causes auto-optimise-store to be broken

Additional context

See a screenshot of a discussion in the Nix on macOS matrix room attached

## Is your feature request related to a problem? Please describe. Right now, to my knowledge, auto-optimise-store causes nix-store corruption on darwin systems. Until it is fixed, lix should not allow users to turn it on darwin. ## Describe the solution you'd like Any error when auto-optimise-store is enabled on darwin would be nice ## Describe alternatives you've considered Investigate and fix the underlying issue that causes auto-optimise-store to be broken ## Additional context See a screenshot of a discussion in the Nix on macOS matrix room attached
Author

Upstream issue on the store corruption (does not discuss prohibiting this option)

[Upstream issue on the store corruption](https://github.com/NixOS/nix/issues/7273) (does not discuss prohibiting this option)
jade added the
bug
label 2024-08-20 16:31:48 +00:00
jade added the
E/help wanted
E/easy
labels 2024-08-23 00:29:11 +00:00
jade added the
OS/macOS
label 2024-10-18 22:11:15 +00:00
Member

Should we hard error, or should we perhaps print a warning and ignore the setting? My concern is if this is an error then when the user hits this they can't run nix profile rollback or nix-env --rollback, and if their nix.conf is managed by something like nix-darwin then that makes recovery more annoying.

Should we hard error, or should we perhaps print a warning and ignore the setting? My concern is if this is an error then when the user hits this they can't run `nix profile rollback` or `nix-env --rollback`, and if their `nix.conf` is managed by something like nix-darwin then that makes recovery more annoying.
Member

Digging into the underlying code, it's hard to trace through all this but it looks like addToStore() can end up invoked from multiple threads, and random() is fundamentally not a thread-safe API (it uses global state), so my best guess is we're simply getting collisions. I just tried a test where I spun up 10 threads and had them generate only 100 numbers each and checked for dupes and I got a lot.

Digging into the underlying code, it's hard to trace through all this but it looks like `addToStore()` can end up invoked from multiple threads, and `random()` is fundamentally not a thread-safe API (it uses global state), so my best guess is we're simply getting collisions. I just tried a test where I spun up 10 threads and had them generate only 100 numbers each and checked for dupes and I got a _lot_.
Member

I submitted https://gerrit.lix.systems/c/lix/+/2100 as a proposed fix for the underlying issue, though I don't know how to actually test the store corruption to make sure this solves it.

I submitted https://gerrit.lix.systems/c/lix/+/2100 as a proposed fix for the underlying issue, though I don't know how to actually test the store corruption to make sure this solves it.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#477
No description provided.