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 ## 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 [Local Overlay Store]. This store allows having multiple physical stores acting
as a single logical store. as a single logical store.
With this approach, stores are layered on top of each other with all but the 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 top-most layer being writable, the others are read-only. Nix will build inside
described in the [Upstream Nix Documentation][Local Overlay Store]. Work is the top-most layer.
[ongoing][lix-local-overlay] to bring the feature to Lix aswell. 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 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 as read-only and having Nix not rebuild/substitute store paths available in
rebuilding/substituting from `cache.nixos.org`. lower layers.
Due to implementation details of this feature, the lower layer(s) can not only 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 be a location on the file system but also have another `nix-daemon` back the
@ -62,7 +63,7 @@ multiple `snix` components.
Stay tuned. Stay tuned.
[castore]: https://snix.dev/docs/components/overview/ [castore]: {{< ref "/docs/components/overview.md" >}}
[bugs]: https://git.snix.dev/snix/snix/issues [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 [Local Overlay Store]: https://nix.dev/manual/nix/2.26/store/types/experimental-local-overlay-store.html
[replit]: https://blog.replit.com/tvix-store [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 $ $(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 To expose the store paths and their contents as a file system, if can be
FUSE-mounted with the following command: 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 --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 ### 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 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 it, this is optional but allows you to have access to your real nix store
without unmounting: without unmounting:
@ -108,11 +123,16 @@ This can be achieved by either setting the env variable
### Profit ### 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. lower store.
Note that snix's FUSE mount might be performing slower than the native {{<callout>}}
file-system depending on your workload. Please file bugs if you notice obviously There are some known (and not yet worked-on) performance issues in Snix
bad performance. 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 [local overlay]: https://nix.dev/manual/nix/2.26/store/types/experimental-local-overlay-store.html