
Ubuntu 20.04’s zsys adds ZFS snapshots to package management - mariuz
https://arstechnica.com/gadgets/2020/03/ubuntu-20-04s-zsys-adds-zfs-snapshots-to-package-management/
======
kstenerud
Oh thank god there's a way to disable autosnapshot! It's been filling my drive
with useless snapshots ever since I installed Ubuntu with zfs support,
drowning out my real snapshots. Who needs a snapshot after calling "apt
install htop" anyway? The ZFS snapshot and grub update processes increase the
install time 3-fold, and run the risk of seriously hooping the system if the
power goes out unexpectedly.

Has anyone had any real problems with apt install or apt remove busting their
systems? Seems more like a solution in search of a problem.

~~~
derefr
> Who needs a snapshot after calling “apt install htop” anyway?

I’d think the more useful feature would be taking a snapshot _at the beginning
of_ the apt run; and then tossing it away if apt manages to complete
successfully. That way, apt returning a nonzero exit status could be caught by
a wrapper script, that would then transactionally revert the changes.

I believe NTFS still does this for Windows updates, even if “transactional
filesystem” features are no longer “available” (i.e. exposed to userland.)

Of course, unlike NTFS’s filesystem transactions, ZFS snapshots aren’t MVCC —
you can’t have multiple parallel ones going on at once that get merged on
success. So that apt-wrapper-script reverting, might throw away something else
you’ve done to your rootfs (and hopefully only your rootfs; such a technique
would effectively require moving all user-mutable data to other mounted
volumes.)

~~~
danudey
Apt completing successfully is not the same thing as the installation
completing successfully. For example, Apt could successfully update a bunch of
libraries, versions, etc. which now breaks your application, but because apt's
actual tasks succeeded the snapshot gets removed and now you can't roll back.

> and hopefully only your rootfs; such a technique would effectively require
> moving all user-mutable data to other mounted volumes

I believe that zfs installation creates a separate dataset for /home, meaning
that it won't be rolled back along with everything else. The same should be
true for things like /var/lib/, but I haven't done such an install in a while,
since the first 20.04 build with zfs enabled.

------
throw0101a
If anyone is wondering about the historical context to this, look up "boot
environments", which first appeared under Solaris with FreeBSD copying the
feature:

* [https://docs.oracle.com/cd/E86824_01/html/E54764/beadm-1m.ht...](https://docs.oracle.com/cd/E86824_01/html/E54764/beadm-1m.html)

* [https://www.freebsd.org/cgi/man.cgi?beadm](https://www.freebsd.org/cgi/man.cgi?beadm)

~~~
drewg123
I've been updating my freebsd-current desktops for quite a few years with
beinstall / beadm, and I love it. The ability to quickly roll back from an
update is critical on a rolling-release OS like freebsd.

------
interrupt_
ZFS is great but aren't we better off focusing on something else like btrfs?
The whole licensing situation makes me nervous to adopt this.

~~~
hestefisk
I think Ubuntu adoption of ZFS is a testament that it is here to stay. Btrfs
still has some issues (eg stability), which ZFS simply doesn’t have. It’s rock
solid.

~~~
Dunedan
> I think Ubuntu adoption of ZFS is a testament that it is here to stay.

Like Mir, Unity, Upstart and all the other technologies Ubuntu adopted, but
removed after a while again? I always have the feeling that the Canonical
engineers try to advance the Linux ecosystem by introducing new technologies,
but somehow always pick the wrong ones, which end up not being adopted
anywhere else. Granted that's different with ZFS, as ZFS already has a large
user base, but there is nothing guaranteeing that Ubuntu won't remove ZFS in a
few years again.

~~~
jlgaddis
As you yourself mentioned, ZFS is different.

The other projects were (for the most part) anonical originals" that they
tried to create -- primarily on their own -- to replace existing products. ZFS
is going on 15 years old, quite mature, highly trusted, and, of course, it
already has a huge existing userbase.

It's certainly not an internal Canonical project that requires them to devote
huge teams of developers to it. Unlike the others you mentioned, ZFS will
continue to exist and grow regardless of Canonical's involvement.

~~~
jlgaddis
> _anonical originals "_

Oof, "Canonical originals", that should have read (not sure what ate the two
missing characters, HN or the iPad).

