Announcement

Collapse
No announcement yet.

Canonical Confirms Their Experimental ZFS Plans For The Ubuntu 19.10 Desktop

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

  • Canonical Confirms Their Experimental ZFS Plans For The Ubuntu 19.10 Desktop

    Phoronix: Canonical Confirms Their Experimental ZFS Plans For The Ubuntu 19.10 Desktop

    We've known for months about Canonical working to ramp up their ZFS On Linux support for Ubuntu 19.10 after initially packaging ZoL for Ubuntu years ago and supporting it in the server space. One of the big changes for Ubuntu 19.10 expected is an experimental ZFS root file-system install option for their desktop GUI installer. That's been confirmed today by Canonical along with some of their related ZoL activities...

    http://www.phoronix.com/scan.php?pag...Experiment-Opt

  • #2
    ctrl+F "grub" -- Oh wow. That was more than I expected to find . Get a few more features upstreamed to GRUB and we won't be reliant on systemd-boot for a full-featured ZoL experience. I dream of that day.

    zsys + Fedora -- Awesome, a possible collaborated ZFS framework and standard for Linux.

    IMHO, while it's only a single developer, this is the more important part of that announcement. One distribution using something makes it a neat concept. More than one distribution using something makes it a tool.

    Comment


    • #3
      I understand why someone would want to have ZFS on their servers, especially when there's a need for RAID5/6 configurations where btrfs still sucks.
      But on desktop? How many people are using RAID5 or RAID-Z on desktop machines?

      So what's the benefit of running ZFS on desktops -- e.g. compared to (if someone really wants volumes snapshotting CRC checks) btrfs? ZFS apparently makes it hard to remove volumes, uses tons of memory when deduplication is enabled, etc (not saying that ZFS is bad, just that each shine in slightly different use-cases).

      I'm not sure that ZFS is some sort of silver bullet as it is often presented. Sure, it is a wonderful filesystem, but it needs some monitoring and maintenance. I'm wondering if this might end up in just the same sort of negative publicity that btrfs used to get, when people assumed they could use it in an install-and-forget mode.

      Both ZFS and btrfs will work fine if properly maintained (with the plethora of caveats that both filesystems have properly documented). I think btrfs got a lot of bad publicity because distributions made it extremely easy to install and people were installing it unaware that it needs maintenance. So they got burnt (I did too) and thus bad publicity. ZFS got luckier in this regard, because it never was easy to install, it always needed some informed people to install it and if that someone went far enough to invest the effort to install it, they probably also read the documentation and were competent enough that they also maintained it properly. So less bad publicity. But if you read the developer forums for btrfs and zfs-on-linux, you'd notice approximately similar frequency of either bug or data-loss reports.

      I'm just hoping that this won't turn bad for ZFS. And I also don't understand all the negativity against btrfs (or is it just emotions of the uninformed, just like vaccination, diesel engines, etc.?).

      Comment


      • #4
        Originally posted by pkese View Post
        And I also don't understand all the negativity against btrfs (or is it just emotions of the uninformed, just like vaccination, diesel engines, etc.?).
        For me the btrfs showstopper was how bad it deals with file fragmentation.
        my vm's performance decreased noticeable. after i discovered this i checked a few more things: eg sqlite db's used by ff and thunderbird - and ditched btrfs completly afterwards.

        i know that i can disable cow on these files. but - for me - thats to complicated because i tend to forget where i did such changes and where i cant rely on cow features.

        so i am still using lvm/ext4 and dont plan to change that anytime soon.

        i am not sure how good zfs deals with fragmentation though. one problem i see is that it is hard to expand an RAID10 Array - something i need.

        Comment


        • #5
          Originally posted by pkese View Post
          So what's the benefit of running ZFS on desktops -- e.g. compared to (if someone really wants volumes snapshotting CRC checks) btrfs? ZFS apparently makes it hard to remove volumes, uses tons of memory when deduplication is enabled, etc (not saying that ZFS is bad, just that each shine in slightly different use-cases).
          Snapshots, how much there is to configure/the ability to optimize for lots of scenarios, per volume compression settings, native encryption, boot environments, overlay support, swap volume support, acts as a workaround for MBR partition limits, and more.

          Why does everyone bring up ZFS and deduplication and memory usage? For an OS using it for root in regards to snapshots and boot environments, the average 8GB of ram system is plenty good enough for that use case. It's around 1GB ram for 1TB of deduplicated data which means we're talking around 10-15GB for a root snapshot in the worst case scenario which is around 75-100 snapshots before 1GB of ram is used up.

          flower
          One trick to deal with ZFS fragmentation is to move a file from one volume to another; like download torrents to pool/working and move them to pool/finished when completed. Another thing to keep in mind is that pools for VMs and DBs need custom settings when compared to something generic like $HOME.

          Comment


          • #6
            Originally posted by skeevy420 View Post
            zsys + Fedora -- Awesome, a possible collaborated ZFS framework and standard for Linux.
            Don't get too excited, my talk on ZFS and its place in Fedora submitted for Flock was rejected. I'll continue my work with zsys but that will be for now separate, unofficial repo. There is no place, currently, for ZoL in the official Fedora release.

            Comment


            • #7
              Originally posted by mskarbek View Post
              Don't get too excited, my talk on ZFS and its place in Fedora submitted for Flock was rejected. I'll continue my work with zsys but that will be for now separate, unofficial repo. There is no place, currently, for ZoL in the official Fedora release.
              Damn

              Comment


              • #8
                Originally posted by mskarbek View Post
                Don't get too excited, my talk on ZFS and its place in Fedora submitted for Flock was rejected. I'll continue my work with zsys but that will be for now separate, unofficial repo. There is no place, currently, for ZoL in the official Fedora release.
                I'll be the first to push for ZoL in Fedora if someone ever implements the FUSE backend for it...

                Comment


                • #9
                  Originally posted by pkese View Post
                  I understand why someone would want to have ZFS on their servers, especially when there's a need for RAID5/6 configurations where btrfs still sucks.
                  But on desktop? How many people are using RAID5 or RAID-Z on desktop machines?

                  So what's the benefit of running ZFS on desktops -- e.g. compared to (if someone really wants volumes snapshotting CRC checks) btrfs? ZFS apparently makes it hard to remove volumes, uses tons of memory when deduplication is enabled, etc (not saying that ZFS is bad, just that each shine in slightly different use-cases).
                  It's not fully intended for the desktop as the primary consumer.

                  We want to support ZFS on root as an experimental installer option, initially for desktop, but keeping the layout extensible for server later on. The desktop will be the first beneficiary in Ubuntu 19.10.
                  However, we are aware that some system administrators are very passionate about the file systems and want to be in control. This is why we designed our system in such a way that it can cope with manual tweaking, is easy to understand for people having some know-how on ZFS, and still remains very flexible.
                  They're porting it to the desktop first so that early adopters and tweakers can help them iron out bugs, but the main intended recipient is still for servers. The ability to near-instantly revert to a point-in-time snapshot makes this an attractive feature for SMBs and organizations that do not maintain a large enough fleet of servers that Chef/Puppet/Ansible is in play. This also is useful for developers, since it lets them experiment and revert in case of breakage.

                  For the desktop, the main draw is snapshots and clones, not RAID.

                  Comment


                  • #10
                    Been using BTRFS a few years on a dozen or two Linux Desktops with minimal problems, occasionally files will have have some sort of sync issue with metadata if there are enough unexpected power outages / hard resets. In that case I just rsync to a different disk and back or try bizare fixes like fixing the metadata and have had problems but nothing massive.

                    I use snapshots religiously multiple times a day on work and boot to cover my ass, they're fantastic. You have a super important work folder? Just snapshot it every hour and when disk space fills up delete old snapshots which only cost the file size of differences since the snapshot.

                    ZFS? Not interested. IIUC it is a fork and out of alignment with current day ZFS, and the idea of using a bastardized filesystem made for another OS natively on Linux with all these hoops to jump through -- I'm sure it's great if you use it at work but if not it sounds like a lot of extra work with minimal benefits for the features I need.

                    Plus, Fuck Oracle and their IP.

                    I have a Fuck Them attitude toward Oracle and Adobe, they are in the corporate money business, not the software innovation business. I hope they loose ground as they have both caused so much unrest and problems for Linux that never needed to happen over the last few decades.

                    Comment

                    Working...
                    X