1. 25
  1.  

  2. 6

    There are spooky articles saying only give ZFS entire disks.

    From what I understand, the reasoning for this (mostly) historical note was:

    1. On solaris/opensolaris, there were some special cases regarding disk write caches with whole disk vs partitioned.
    2. It is easier to just slap in a replacement disk if you don’t have to partition anything on the new disk (lower operator complexity).
    3. I further hypothesize an additional possible reason – an attempt to avoid confusion/footguns for new users at the time (when zfs was very new) regarding disk/pool failure semantics (eg. avoid people putting multiple zpools on the same disk or multiple vdevs for the same pool on the same disk).

    For FreeBSD (and Linux too, I think) I believe the first reason is not a concern, as it was solaris specific.

    refs:

    1. 4

      Nice work. Graham, do you have any thoughts about what it would take to have NixOS manage system generations with ZFS, considering that you can read-only mount snapshots? It seems like a natural extension to keep the Nix store in a ZFS snapshot. OpenIndiana does this already, it’s pretty slick and is the closest thing I’ve seen to Nix’s atomicity.

      1. 2

        It was interesting to hear Greg Kroah-Hartman’s suprising to me comments on the stability of ZFS on Linux in a recent AMA.

        “You are relying on a kernel module that no one in the kernel community can ever touch, help out with, or debug. The very existence of the kernel module is at the whim of the kernel itself not doing something that might end up breaking it either with api changes, or functional changes, as the kernel community does not know what is in that code, nor does it care one bit about it.”

        https://www.reddit.com/r/linux/comments/fx5e4v/im_greg_kroahhartman_linux_kernel_developer_ama/fn5t6t4

        Slightly scary considering how important correctness is when talking about filesystems. I’ve been using btrfs recently but prefer ZFS and would like more explicit kernel support.

        1. 8

          It was interesting to hear Greg Kroah-Hartman’s suprising to me comments on the stability of ZFS on Linux in a recent AMA: “You are relying on a kernel module that no one in the kernel community can ever touch, help out with, or debug. […]”

          Slightly scary considering how important correctness is when talking about filesystems.

          That ZFS on Linux is an unsupported external module is scary. But relying on filesystems such as ext4 or XFS that do not have any measures in place against data silent data corruption is, to me, even scarier.

          1. 1

            What about btrfs? I use it at work and it seems to work pretty well.

          2. 6

            They have a point, but you’ve got to pick the least risky option that provides the features you want.

            I’ve ran btrfs. I’ve ran zfs. I’ve used snapshots/subvolumes on both. Btrfs was flaky and I lost data. ZFS was a joy to use and I have not lost data.

            1. 5

              the kernel community does not know what is in that code, nor does it care one bit about it

              An even stronger argument could be made for 99% of flagship Android phones shipping proprietary, out of tree modules. Yet, ZFS is open source and gets flak anyway because it’s not GPL.

              I think we’d all like to see ZFS ship with the Linux kernel, but adding boot.supportedFilesystems = ["zfs"] to my nix config isn’t really ever going to be a huge deal. So, really, this entire line of argument is just more party-line GPL bickering, nothing new to see here.

              1. 4

                The position Greg, and seemingly others in the Linux project, take on this is persistently tedious – for ZFS users and developers alike. All I can suggest is that there are other UNIX platforms that make different trade-offs, and which don’t have a frustrating relationship with ZFS; e.g., illumos or FreeBSD.