Announcement
Collapse
No announcement yet.
Ubuntu 20.04 Atop ZFS+Zsys Will Take Snapshots On APT Operations
Collapse
X
-
Originally posted by Britoid View Post
I see including it as a little insulting to the upstream Linux developers, as surely it would be better to try and improve and work on btrfs.
I wish Silverblue had a ZFS or BTRFS backends. ZFS+Zsys has a really good chance at giving both Suse's BTRFS snapshot solution and Fedora's Silverblue atomic solution runs for their money. I'm really hoping that Stratis is Hat answer to ZFS+Zsys.
Leave a comment:
-
Originally posted by anarki2 View PostDo what?
The problem is that the use of a separate /home is neve enforced and that stuff is written everywhere, not just in /home. /home is the most frequent one, but not the only one. That's why I said, "at the bare minimum".
I know it's strange to assume Canonical will do a decent job, but if they use the same thing and split stuff in different volumes they can do the same.
This is a OpenSUSE install default volume division of a btrfs root (databases are by default in their own folder in /var, which as you see is split in its own volume)
Code:mount | grep sda /dev/sda1 on / type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=267,subvol=/@/.snapshots/1/snapshot) /dev/sda1 on /.snapshots type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=266,subvol=/@/.snapshots) /dev/sda1 on /boot/grub2/i386-pc type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=265,subvol=/@/boot/grub2/i386-pc) /dev/sda1 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=264,subvol=/@/boot/grub2/x86_64-efi) /dev/sda1 on /opt type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=263,subvol=/@/opt) /dev/sda1 on /root type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=262,subvol=/@/root) /dev/sda1 on /srv type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=261,subvol=/@/srv) /dev/sda1 on /var type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=258,subvol=/@/var) /dev/sda1 on /usr/local type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=259,subvol=/@/usr/local) /dev/sda1 on /home type btrfs (rw,relatime,compress-force=zstd:3,ssd,nospace_cache,clear_cache,autodefrag,subvolid=268,subvol=/@/home)
But for example, if you have a DB engine running, it won't exactly be thankful for rolling back to a mid-transaction state. All system-wide stuff you do will be reverted. This approach begs for apocalypse. apt has to deal with transactions within its own realm, not on the filesystem level.
If you don't keep your system and home folders split up it can be annoying as any rollback will rollback EVERYTHING, but it won't be unsafe.
As explained above, it's easy to exclude folders from this snapshotting
That's perfectly irrelevant,
The point is, this kind of issue has been resolved for decades on other system, Linux developers still fail to do it, and instead come up with abominations like this.
Also if we want to talk about abominations we can talk about Windows "system restore points" for example which are in many cases completely useless, using a CoW filesystem to make a snapshot of the root filesystem would replicate a "system restore point" functionality that actually works reliablyLast edited by starshipeleven; 07 March 2020, 04:07 PM.
- Likes 8
Leave a comment:
-
Originally posted by anarki2 View PostThe relevance lies in the fact that it's Red Hat deprecating it,
- Likes 4
Leave a comment:
-
Originally posted by starshipeleven View PostCoW filesystems can do that
Originally posted by starshipeleven View Postin OpenSUSE, stuff is split into different volumes (zvols in ZFS or whatever else in btrfs) so it won't snapshot your stuff in the home folder for rolling back system updates, but it's a convenience thing, it's not like dangerous or anything.
But for example, if you have a DB engine running, it won't exactly be thankful for rolling back to a mid-transaction state. All system-wide stuff you do will be reverted. This approach begs for apocalypse. apt has to deal with transactions within its own realm, not on the filesystem level.
Originally posted by starshipeleven View PostToo bad it's not as commonly used as normal installers that can and will screw up the installed application.
- Likes 1
Leave a comment:
-
Originally posted by starshipeleven View PostI'm not seeing how deprecating something they never really used at all has any relevance.
Leave a comment:
-
Originally posted by DanL View PostWe've already had complainers like the FSF. But the only complaint that matters is if Oracle decides to sue. And Canonical has already cleared their action with the SFLC, so grounds for that would be shaky.
Perceived legality is irrelevant, once a legal battle ensues whoever has (a lot) more money or better legal team usually wins.
- Likes 1
Leave a comment:
-
Originally posted by mskarbek View PostBtrFS is worked on and improved for how many years? It still doesn't work as it should
RAID5/6 are also fine (according to Oracle among others, just check their "unbreakable *cough*RHEL clone*cough* Linux" product website) if used in serious deployments where you always have an UPS.
I'm just wondering how long this will go until Linux devs reexport everything as GPL-only to "punish" Canonical and others who would like to have something useful as a file system
If they keep their current profile they are safe from most "big fish" so to speak. If they start growing into RedHat-sized company then they might be in trouble.
- Likes 5
Leave a comment:
-
Originally posted by anarki2 View PostRed Hat deprecating btrfs has been pretty much the last nail in the coffin, let it go.
- Likes 4
Leave a comment:
-
Originally posted by anarki2 View PostUnless you run nothing else during apt transactions, this is bound to cause problems.
A separate /home should be mandatory, at the bare minimum.
MSI supported rollbacks for decades. It may or may not install, but at least it won't break MSI installs altogether.
- Likes 7
Leave a comment:
Leave a comment: