5 ms·

> if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited

by m1keil 5y ago

> if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited to disk. Usually they look the same, but not always. Could you elaborate on this? If I have state that works on v1 and after upgrade to v2 the state is now non backward compatible to v1, how nix (or guix) can help? As far as I can tell, in such case a fs rollback is better solution.

kaba0 5y ago
What state do you mean? Let’s say you have a backup of your system partition but your home folder is separate. In that case a rollback with the filesystem is the same as one through nix — the latter will place symlinks to all the previous versions and the finished result is identical. Of course if you have in the meanwhile used the new system and your home folder contains some backwards incompatible changes, both solutions will fail. Rolling back your home folder may not be a good thing as you may have backwards compatible changes you prefer. Also, nix can also manage installed application’s configs, so those could also be rolled back, on either a per-app basis or however you prefer.
- jordanbeiber 5y ago
  Sure you could, like Solaris did IIRC, zfs snapshot before updates was applied. What I mean is that a fs snapshot is ”dumb” in and of it self. If you couple zfs with the nixos rebuild command, then… sure, I guess - but the previous generations are already more or less directly available, unless GC’d. This is what the fine manual has to say: Since Nix is good at being Nix, most users will want their server's data backed up, and don't mind reinstalling NixOS and then restoring data.
pxc 5y ago
Depends on how the state is stored. If it's in configuration, Nix generated it and it lives immutable in the Nix store, so Nix will just point out it to the old version on rollback. If it's something like the content of a SQL database, which lives outside the Nix store and which Nix did not generate, you need some other tool (like a filesystem snapshot, maybe) to perform the rollback. I think CoW filesystems sometimes have performance issues with DBs, though, so I'm not sure that's always the approach you'd take. The Nix ecosystem does have a fairly mature tool for managing stateful components that live outside the Nix store, though: https://github.com/svanderburg/dysnomia https://github.com/svanderburg/dysnomia It's been around for a long time. Idk who all is using it

by m1keil 5y ago

kaba0 5y ago

What state do you mean? Let’s say you have a backup of your system partition but your home folder is separate. In that case a rollback with the filesystem is the same as one through nix — the latter will place symlinks to all the previous versions and the finished result is identical. Of course if you have in the meanwhile used the new system and your home folder contains some backwards incompatible changes, both solutions will fail. Rolling back your home folder may not be a good thing as you may have backwards compatible changes you prefer. Also, nix can also manage installed application’s configs, so those could also be rolled back, on either a per-app basis or however you prefer.

jordanbeiber 5y ago
Sure you could, like Solaris did IIRC, zfs snapshot before updates was applied. What I mean is that a fs snapshot is ”dumb” in and of it self. If you couple zfs with the nixos rebuild command, then… sure, I guess - but the previous generations are already more or less directly available, unless GC’d. This is what the fine manual has to say: Since Nix is good at being Nix, most users will want their server's data backed up, and don't mind reinstalling NixOS and then restoring data.

pxc 5y ago

Depends on how the state is stored. If it's in configuration, Nix generated it and it lives immutable in the Nix store, so Nix will just point out it to the old version on rollback. If it's something like the content of a SQL database, which lives outside the Nix store and which Nix did not generate, you need some other tool (like a filesystem snapshot, maybe) to perform the rollback. I think CoW filesystems sometimes have performance issues with DBs, though, so I'm not sure that's always the approach you'd take. The Nix ecosystem does have a fairly mature tool for managing stateful components that live outside the Nix store, though: https://github.com/svanderburg/dysnomia https://github.com/svanderburg/dysnomia It's been around for a long time. Idk who all is using it