fix(web/blog/overlay-store): another editing pass

Add a bit more information, callouts to prevent people potentially
bricking their laptops.

Also change the performance section, we will

Change-Id: Id516c4bb0f0c2cbe99db86199b91c7d68becdd44
Reviewed-on: https://cl.snix.dev/c/snix/+/30254
Autosubmit: Florian Klink <flokli@flokli.de>
Tested-by: besadii
Reviewed-by: Ilan Joselevich <personal@ilanjoselevich.com>
This commit is contained in:
Florian Klink 2025-03-23 01:23:28 +00:00 committed by clbot
parent 754cbbe4ad
commit 1fab06d851
2 changed files with 35 additions and 14 deletions

View file

@ -14,18 +14,19 @@ homepage: false
## Background
About a year ago, nix introduced a new experimental store type:
About a year ago, Nix introduced a new experimental store type:
[Local Overlay Store]. This store allows having multiple physical stores acting
as a single logical store.
With this approach, stores are layered on top of each other with all but the
top-most layer being writable, the others are read-only. The feature is
described in the [Upstream Nix Documentation][Local Overlay Store]. Work is
[ongoing][lix-local-overlay] to bring the feature to Lix aswell.
top-most layer being writable, the others are read-only. Nix will build inside
the top-most layer.
The feature is described in the [Upstream Nix Documentation][Local Overlay Store].
Work is [ongoing][lix-local-overlay] to bring the feature to Lix aswell.
The main use-case is for it is having a large nix store mounted onto a machine
as read-only and configure nix to use data stored in it to avoid
rebuilding/substituting from `cache.nixos.org`.
The main use-case is for it is having a large Nix store mounted onto a machine
as read-only and having Nix not rebuild/substitute store paths available in
lower layers.
Due to implementation details of this feature, the lower layer(s) can not only
be a location on the file system but also have another `nix-daemon` back the
@ -62,7 +63,7 @@ multiple `snix` components.
Stay tuned.
[castore]: https://snix.dev/docs/components/overview/
[castore]: {{< ref "/docs/components/overview.md" >}}
[bugs]: https://git.snix.dev/snix/snix/issues
[Local Overlay Store]: https://nix.dev/manual/nix/2.26/store/types/experimental-local-overlay-store.html
[replit]: https://blog.replit.com/tvix-store

View file

@ -39,7 +39,7 @@ You can run the daemon with:
$ $(nix-build -A snix.snix-store)/bin/snix-store daemon
```
### Mount the castore onto your file system
### Mount the store
To expose the store paths and their contents as a file system, if can be
FUSE-mounted with the following command:
@ -61,10 +61,25 @@ $ $(nix-build -A snix.nix-daemon)/bin/nix-daemon -l /tmp/snix-daemon.sock \
--unix-listen-unlink
```
This will launch the `snix` nix-daemon listening on a unix domain socket
This will launch the `snix` nix-daemon listening on a unix domain socket.
Nix will communicate with it to get metadata about store paths.
### Create an overlayfs mount
{{<callout>}}
Depending on your usecase, this might not be appropriate for a physical NixOS
system, replacing `/nix` globally.
In these cases, you want to ensure store paths needed to boot the system are
available on the plain disk.
You most likely want to mount this combined mountpoint elsewhere, and spin up a
separate mount namespace (via `systemd-nspawn`, `bwrap` or similar) exposing it
at `/nix` in there. You have been warned!
{{</callout>}}
Bind mount your real /nix store on the side, so that nix has direct access to
it, this is optional but allows you to have access to your real nix store
without unmounting:
@ -108,11 +123,16 @@ This can be achieved by either setting the env variable
### Profit
With the above setup you should now be able to have nix use Snix Castore as its
With the above setup you should now be able to have nix use Snix castore as its
lower store.
Note that snix's FUSE mount might be performing slower than the native
file-system depending on your workload. Please file bugs if you notice obviously
bad performance.
{{<callout>}}
There are some known (and not yet worked-on) performance issues in Snix
castore, which is why the mount is expected to perform slower than the native
file-system. Depending on your workload, this might or might not be an issue.
Check [our Bug tracker][castore-perf-issues] for updates on that topic.
{{</callout>}}
[castore-perf-issues]: https://git.snix.dev/snix/snix/issues?q=&type=all&sort=&labels=14%2c24
[local overlay]: https://nix.dev/manual/nix/2.26/store/types/experimental-local-overlay-store.html