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

  • #11
    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.

    Comment


    • #12
      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.

      Comment


      • #13
        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 [email protected], buggy, and unnecessary.

        Comment


        • #14
          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.

          Comment


          • #15
            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.

            Comment


            • #16
              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; 03-07-2020, 04:07 PM.

              Comment


              • #17
                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.

                Comment


                • #18
                  What has apt/yum/etc ever broken anyway?

                  Comment


                  • #19
                    Originally posted by mskarbek View Post

                    Insulting how? BtrFS is worked on and improved for how many years? It still doesn't work as it should, so I'm not surprised that Canonical started working with something that is actually usable.
                    What doesn't not work in BTRFS as it should? Aside from RAID 5/6 of course because it's not secret that is still problematic. Any more? Honestly I couldn't see problems on my computers where I'm using Btrfs in root partition. Partitions are still fine even after several power losses.

                    As for new feature in Ubuntu - openSUSE has this since years. Without using out of tree filesystems.

                    Comment


                    • #20
                      Originally posted by elatllat View Post
                      What has apt/yum/etc ever broken anyway?
                      Just one more tool to theoretically easily roll back in the event of unforeseen problems with updated packages. There's always a non-zero chance some bug either in hardware or software can render your system unable to boot or complete the boot process.

                      Just this week there was a one line configuration problem in a Ubuntu 20.04 plymouth update that rendered mkinitramfs unable to complete building its initramfs. Mistakes happen.

                      Comment

                      Working...
                      X