[paludis-user] Paludis/transaction merging

Rich Freeman r-paludis at thefreemanclan.net
Wed May 2 14:57:30 UTC 2012


On Wed, May 2, 2012 at 4:49 AM, denisgolovan <denisgolovan at yandex.ru> wrote:
>> > However, by the time somebody implements all of this, it might make
>> > more sense to just target btrfs instead. Just create a snapshot of
>> > root before doing a merge, or merge into a new snapshot.
>> >
>
> Do you mean it is possible to mount this snapshot in a chroot, install/update/revdep and merge changes back?

There are a couple of ways of doing this:

1.  Keep a snapshot as a backup, so you work in your live filesystem,
and potentially break it, but you can easily switch back to the
snapshot if you need to.

2.  Use the snapshot to stage the changes.  Then to actually use the
changes you'd have to pivot to the new root - which usually requires a
reboot.

So #1 forces you to reboot if something goes wrong, and #2 forces you
to reboot if everything goes right.  #1 is probably more suited to
more casual/desktop uses, and #2 is probably more suited to more
server-like setups.

The issue with either is changes happening to the system beyond the
PM-related changes, such as to files in /home, /var, etc.  Those
changes get lost when you switch your root (either if something goes
wrong, or right, again depending on which method you employ).  The
only way to get around this easily is to have separate snapshots on
things that you actually change, like /usr, /var/lib, and so on.  For
/usr that probably is easy to do, for things like /etc it is probably
manageable, and for all the junk that goes under /var it could get
tricky since that is a mix of stuff that changes more and less
frequently.

There are probably more sophisticated solutions, like namespaces/etc,
that can be used to give different processes different views of the
filesystem (see some of the stuff systemd is doing with this, like
private /tmp, read-only paths, and so on).  All of these solutions
suffer from the need to enumerate what should and shouldn't persist a
revert/deploy.

In the end probably the easiest thing to do is to use snapshots as a
low-downtime fallback solution, and use a chroot and binary packages
to handle testing.

If you have to restore from the snapshot but don't want to lose data,
you could chroot to the snapshot, quickpkg your old configuration, and
then restore it to your production root.

I suspect there are some potentially clever solutions out there which
utilize some of the newer features between LXC, namespaces, and COW
filesystems.  We're both hinting at some of them, and I suspect there
are some more elegant solutions still waiting to be discovered.

Rich



More information about the paludis-user mailing list