• Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      46
      ·
      edit-2
      9 days ago

      I wish the licensing would be Linux compatible

      Overall solid but BTRFS has the advantage of being Linux native in the way it works. Right now I wouldn’t use btrfs for a critical raid system but it is great for single disks.

      • ZkhqrD5o@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        9 days ago

        But we have OpenZFS, which is under CDDL (=LGPL). So it’s fine.

        Edit: I was wrong, see comment below.

              • ZkhqrD5o@lemmy.world
                link
                fedilink
                arrow-up
                6
                ·
                9 days ago

                Oh dear, I didn’t know that. Thanks for the info. I genuinely wish that people would stop using these pushover licenses. I thought it was like the LGPL, but sadly it isn’t. At least the base remains free though.

                • Natanael@infosec.pub
                  link
                  fedilink
                  arrow-up
                  5
                  ·
                  9 days ago

                  It’s kinda comparable in terms, but because both licenses have comparable copyleft “no rights may be removed and no terms added” restrictions they conflict and can’t be merged.

                  CDDL came after GPL, and I’m not convinced by the arguments for why it was used (to make some kind of development with commercial modules easier, but this could’ve been done with GPL + exceptions)

                  That license plus patents (which only are freely licensed to the CDDL implementation specifically) means you can’t just rewrite it for Linux either. You’d have to wait for the patents to expire and then do clean room reverse engineering.

    • prole@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      9
      ·
      9 days ago

      As someone who uses btrfs mostly (sometimes ext4, but I don’t really know why…), can someone explain the benefits of ZFS over the previous two I mentioned?

      • ZkhqrD5o@lemmy.world
        link
        fedilink
        arrow-up
        12
        ·
        9 days ago

        The two biggest benefits are that it’s basically a finished implementation of btrfs (see data corruption in large pools and raid 5 and 6), as well as being able to encrypt and compress at the same time.

        Plus, and I don’t know if this is a ZFS-specific thing, being able to group disks into VDevs and not just into one big raid.

        • timbuck2themoon@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          4
          ·
          8 days ago

          Tbf, the one thing I find nice, at least for home users, is the ability to throw JBOD and it makes it all work. Less cumbersome for newcomers. Zfs needs disks of the same size or it will only group disks into a vdev and use the smallest of the disks for capacity.

          That said, I run zfs and no btrfs anywhere. Had high hopes for bcachefs but… That’s not going particularly well.

          • ZkhqrD5o@lemmy.world
            link
            fedilink
            arrow-up
            3
            ·
            8 days ago

            Different tools, different jobs. On my computer I also use btrfs, but on the family archive server ZFS (TrueNAS Scale). Right tool for the right job.

        • prole@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          4
          arrow-down
          1
          ·
          9 days ago

          Thanks for the info. Does ZFS allow for easy snapshotting like btrfs? Or like the stuff in the backend that allows you to do things like, say, edit a filename while the file is open?

          • WhyJiffie@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            7
            ·
            9 days ago

            edit a filename while the file is open?

            that should work on all filesystems on linux, shouldn’t it? linux keeps file handles by inode number, not filename. this is also the reason system updates can happen while everything is running, because replacing the open files is possible too, and the processes that opened it earlier keep seeing the old version of it

          • ZkhqrD5o@lemmy.world
            link
            fedilink
            arrow-up
            5
            ·
            9 days ago

            Snapshots like btrfs, yes. But I think every copy-on-write system can do that. But I don’t know about the rest.

          • suicidaleggroll@lemm.ee
            link
            fedilink
            English
            arrow-up
            3
            ·
            8 days ago

            Does ZFS allow for easy snapshotting like btrfs?

            Absolutely

            edit a filename while the file is open

            Any Linux filesystem will do that

  • lunarul@lemmy.world
    link
    fedilink
    arrow-up
    49
    ·
    edit-2
    8 days ago

    I zoomed in to read what they’re saying on the bottom right and was disappointed.

        • WhyJiffie@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          1
          ·
          edit-2
          9 days ago

          it doesn’t snap like a pro, though. I’m not a windows fan, but the NTFS snapshotting tech, the Volume Shadowcopy service on windows, notifies databases and whatever that is subscribed to it so that they can finish writing whatever is in the pipeline, and receive feedback from writers when they are done to know when to proceed.

          as I know, linux does not have such a mechanism. without it restoring a snapshot made on a running system is exactly like booting from a crash.

          sure better than nothing. but it’s not like a pro.

  • brucethemoose@lemmy.world
    link
    fedilink
    arrow-up
    26
    arrow-down
    2
    ·
    edit-2
    9 days ago

    IDK what they mean by better ssd I/O performance, btrfs was the worst FS I tested for some heavy SSD workloads (like writing thousands of little pngs in short time, file searches, merging huge weights with some paging)…

    The features are fantastic, especially for HDDs, but it’s an inherently high overhead FS.

    ext4 was also bad. F2FS and XFS are great, and I’ve stuck with F2FS for now.

  • Possibly linux@lemmy.zip
    link
    fedilink
    English
    arrow-up
    20
    ·
    9 days ago

    What’s the problem with btrfs really?

    It is nice but it also feels like it is perpetually unfinished. Is there some major flaw in the design?

    • swab148@lemm.ee
      link
      fedilink
      arrow-up
      22
      ·
      9 days ago

      Mostly just the RAID5 and 6 instability, it’s fantastic otherwise. But I’m kinda excited to try out bcachefs pretty soon, as well.

          • Possibly linux@lemmy.zip
            link
            fedilink
            English
            arrow-up
            4
            arrow-down
            1
            ·
            8 days ago

            The Linux kernel uses mailing lists so technically it is called a patch.

            I think the biggest issue was that Kent had/has a attitude problem. It feels weird to pick a fight with Torvalds since he is kind of known for destroying devs but Kent did it anyway.

    • enumerator4829@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      15
      arrow-down
      1
      ·
      9 days ago

      I’ve seen ZFS in production use on pools with hundreds of TBs, clustered together into clusters of many PBs. The people running that don’t even think about BTRFS, and certainly won’t actively consider it for anything.

      • BTRFS once had data corruption bugs. ZFS also had that, but only in very specific edge cases. That case was taken very seriously, but basically, ZFS has a reputation for not fucking up your bits even close to BTRFS
      • ZFS was built and tested for use on large pools from the beginning, by Sun engineers from back when Sun was fucking amazing and not a pile of Oracle managed garbage. BTRFS still doesn’t have stable RAID5/6.
      • ZFS send/recv is amazing for remote replication of large filesystems.
      • DRAID is kind o the only sane thing to do with todays disk sizes, speeds and pool sizes.

      But those are ancillary reasons. I’ll quote the big reason from the archwiki:

      The RAID 5 and RAID 6 modes of Btrfs are fatally flawed, and should not be used for "anything but testing with throw-away data”.

      For economic reasons, you need erasure coding for bigger pools, either classic RAID5/6 or DRAID. BTRFS will either melt your data in RAID5/6 or not support DRAID at all.

    • WhyJiffie@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 days ago

      mergerfs in the kernel would be cool for better performance.

      for those that don’t know, it’s a FUSE based filesystem, which is also cool, but can be slow at times.

      • WalnutLum@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        8 days ago

        Weirdly enough because of the way mergerfs does writes across multiple drives, the main issue that FUSE filesystems face performance wise (namely writing a bunch of small files and their metadata) actually gets pretty well mitigated.

  • JonnyRobbie@lemm.ee
    link
    fedilink
    English
    arrow-up
    2
    ·
    8 days ago

    what’s the advantage of raid 5&6 over something like raid 4&5 - it reads essentially the same to me - a parity redundancy.

    • InverseParallax@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      8 days ago

      4 is bad because parity is on one drive so no matter what happens that drive is the write bottleneck. Raid5 is basically raid4 + raid0.

      5 is just fine but low safety, I run 6 always and it has basically never let me down.