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.
Problems due to apt operations should be pretty rare, but even uncommon events can be worth de-risking. The value in providing this kind of feature is:
* For expert users who have hosed a system -- particularly if it happens to be a production host -- there's an immediate sense of relief and ability to rollback safely, confidently and quickly.
* For less-experienced users who run into problems, there is a convenient and straightforward way for their technical support to explain to them how they can restore their system to a previous state.
Since hosts and their installed packages have varying hardware and configuration states and update/maintenance schedules, incompatibilities and breaking changes are likely to occur occasionally and that's where snapshots can help.
> 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.)
> The ZFS snapshot and grub update processes increase the install time 3-fold
Creating ZFS snapshots is almost instantaneous due to the CoW nature of the filesystem. Is it deleting old snapshots during that process? If so, I'd suggest checking to make sure you have the async_destroy feature enabled for your pool.
If anyone is wondering about the historical context to this, look up "boot environments", which first appeared under Solaris with FreeBSD copying the feature:
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.
BTRFS at this point feels a lot like a sunk cost fallacy - it proved its unreliability too many times over the years, and working on it feels like throwing good money after bad.
Understandably some people may be more interested in not losing their data than the licensing headaches it may come with, so ZFS it is.
Some, like yours truly, run FreeBSD on their NAS, where there are no license issues either, and are very happy it rebased on OpenZFS recently.
> ZFS is great but aren't we better off focusing on something else like btrfs?
Btrfs was originally introduced in Linux 2.6.29 in March 2009. It is still flakey in many situations.
ZFS was first release in Solaris 10 6/06 in June 2006, with it being open source almost right away. OpenZFS was forked in August 2010.
Should Btrfs at some point simply be declared a sunk cost and something new be created? Because from the outside it looks like it's hardly gaining any traction because of its reputation for eating data (maybe only with its RAID code, but still).
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.
I don't think this deserves the down votes. I love ZFS, use ZFS and I'd still say that the licensing issue is real. Just because Oracle hasn't sued Canonical doesn't mean they can't or won't.
[+] [-] kstenerud|5 years ago|reply
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.
[+] [-] jka|5 years ago|reply
* For expert users who have hosed a system -- particularly if it happens to be a production host -- there's an immediate sense of relief and ability to rollback safely, confidently and quickly.
* For less-experienced users who run into problems, there is a convenient and straightforward way for their technical support to explain to them how they can restore their system to a previous state.
Since hosts and their installed packages have varying hardware and configuration states and update/maintenance schedules, incompatibilities and breaking changes are likely to occur occasionally and that's where snapshots can help.
[+] [-] derefr|5 years ago|reply
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.)
[+] [-] craftkiller|5 years ago|reply
Creating ZFS snapshots is almost instantaneous due to the CoW nature of the filesystem. Is it deleting old snapshots during that process? If so, I'd suggest checking to make sure you have the async_destroy feature enabled for your pool.
[+] [-] viraptor|5 years ago|reply
You have a snapshot to go back to in that case. It saves you exactly from power-loss kind of situation.
[+] [-] AnIdiotOnTheNet|5 years ago|reply
Yes, but even so it is far rarer than being frustrated waiting for f'ing grub update.
[+] [-] throw0101a|5 years ago|reply
* https://docs.oracle.com/cd/E86824_01/html/E54764/beadm-1m.ht...
* https://www.freebsd.org/cgi/man.cgi?beadm
[+] [-] drewg123|5 years ago|reply
[+] [-] interrupt_|5 years ago|reply
[+] [-] gruturo|5 years ago|reply
Understandably some people may be more interested in not losing their data than the licensing headaches it may come with, so ZFS it is.
Some, like yours truly, run FreeBSD on their NAS, where there are no license issues either, and are very happy it rebased on OpenZFS recently.
[+] [-] throw0101a|5 years ago|reply
Btrfs was originally introduced in Linux 2.6.29 in March 2009. It is still flakey in many situations.
ZFS was first release in Solaris 10 6/06 in June 2006, with it being open source almost right away. OpenZFS was forked in August 2010.
Should Btrfs at some point simply be declared a sunk cost and something new be created? Because from the outside it looks like it's hardly gaining any traction because of its reputation for eating data (maybe only with its RAID code, but still).
[+] [-] hestefisk|5 years ago|reply
[+] [-] Hackbraten|5 years ago|reply
Still, I’d love to see more people adopt btrfs because I think diversity in filesystems is a good thing.
[+] [-] abrookewood|5 years ago|reply
[+] [-] 2OEH8eoCRo0|5 years ago|reply