Announcement

Collapse
No announcement yet.

Ubuntu 20.04 Atop ZFS+Zsys Will Take Snapshots On APT Operations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • elatllat
    replied
    What has apt/yum/etc ever broken anyway?

    Leave a comment:


  • skeevy420
    replied
    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.
    Don't you mean Stratis?

    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:


  • starshipeleven
    replied
    Originally posted by anarki2 View Post
    Do what?
    Safe snapshots while running? Isn't this one of the main selling points of CoW filesystems?

    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".
    OpenSUSE splits more than just home. Stuff in volumes won't be affected by snapshots of root volume.

    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.
    Are you aware of how CoW filesystems work? there is no "mid-transaction state", the whole fileystem does atomic operations, the snapshot will contain the DB either before or after the transaction.

    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,
    Well, no it isn't. If none uses it outside of some rare software it's still a failure.

    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.
    No it has not been resolved because MSI installers are uncommon at best.
    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 reliably
    Last edited by starshipeleven; 07 March 2020, 04:07 PM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by anarki2 View Post
    The relevance lies in the fact that it's Red Hat deprecating it,
    They never did anything to develop it in the first place, stop this bs.

    Leave a comment:


  • anarki2
    replied
    Originally posted by starshipeleven View Post
    CoW filesystems can do that
    Do what?

    Originally posted by starshipeleven View Post
    in 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.
    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".

    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 Post
    Too bad it's not as commonly used as normal installers that can and will screw up the installed application.
    That's perfectly irrelevant, obviously Microsoft can't prohibit people from using NSIS or Inno or whatever. 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.

    Leave a comment:


  • anarki2
    replied
    Originally posted by starshipeleven View Post
    I'm not seeing how deprecating something they never really used at all has any relevance.
    The relevance lies in the fact that it's Red Hat deprecating it, not the fact that they only supported it as a technology preview. Red Hat is the biggest and most competent contributor in the Linux world. Canonical only has failures to its name, like bazaar, mir, ubuntu touch, unity, subiquity or netplan. All half-@ssed, buggy, and unnecessary.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by DanL View Post
    We'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.
    The thing that is breached is the GPL so anyone with some contributions to Linux kernel can sue. Oracle is just one of many that can do so (and admittedly, a likely one).

    Perceived legality is irrelevant, once a legal battle ensues whoever has (a lot) more money or better legal team usually wins.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by mskarbek View Post
    BtrFS is worked on and improved for how many years? It still doesn't work as it should
    RAID1/0/10 are fine and distros have been using that for a long while with no issues.
    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
    That's just stupid. The real issue is Oracle or any other legal troll that wants a share of Canonical's profits.
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by anarki2 View Post
    Red Hat deprecating btrfs has been pretty much the last nail in the coffin, let it go.
    I'm not seeing how deprecating something they never really used at all has any relevance.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by anarki2 View Post
    Unless you run nothing else during apt transactions, this is bound to cause problems.
    CoW filesystems can do that

    A separate /home should be mandatory, at the bare minimum.
    in 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.

    MSI supported rollbacks for decades. It may or may not install, but at least it won't break MSI installs altogether.
    Too bad it's not as commonly used as normal installers that can and will screw up the installed application.

    Leave a comment:

Working...
X