• JonnyRobbie@lemm.ee
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 hour 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.

      • Nonononoki@lemmy.world
        link
        fedilink
        arrow-up
        9
        arrow-down
        1
        ·
        11 hours ago

        LUKS encrypts the whole drive, native FS encryption can encrypt it partially (e.g. just the home partition). Additionally, decrypting without a keyboard is a pain or impossible (e.g. touch screen only devices).

        • RichardTickler@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          3 hours ago

          If the home/root partition is a physical or logical volume you most certainly can leave that decrypted while encrypting other volumes. The system could not boot if that were the case as the efi partition cannot be encrypted.

        • Petter1@lemm.ee
          link
          fedilink
          arrow-up
          2
          ·
          9 hours ago

          PostmarkedOS was able to encrypt disk while offering on screen touch keyboard to unlock it on my pinePhone “pro”.

        • prole@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          9 hours ago

          I’m the furthest thing from an expert in linux encryption, but can you not use KDE’s “Vaults” feature to create encrypted folders/drives? I think it uses “CryFS” as the backend (according to KDE. Don’t really know enough about it).

          I’ve used them on my btrfs drive and seemed to work fine.

  • lunarul@lemmy.world
    link
    fedilink
    arrow-up
    40
    ·
    18 hours ago

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

  • brucethemoose@lemmy.world
    link
    fedilink
    arrow-up
    25
    arrow-down
    2
    ·
    edit-2
    18 hours 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.

    • prole@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      5
      ·
      9 hours 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
        6
        ·
        8 hours 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.

        • prole@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          3
          arrow-down
          1
          ·
          8 hours 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
            4
            ·
            7 hours 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

          • suicidaleggroll@lemm.ee
            link
            fedilink
            English
            arrow-up
            1
            ·
            6 hours ago

            Does ZFS allow for easy snapshotting like btrfs?

            Absolutely

            edit a filename while the file is open

            Any Linux filesystem will do that

          • ZkhqrD5o@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            8 hours ago

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

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      40
      ·
      edit-2
      22 hours 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.

    • WhyJiffie@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      6 hours 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
        ·
        6 hours 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.

  • Possibly linux@lemmy.zip
    link
    fedilink
    English
    arrow-up
    20
    ·
    22 hours 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?

    • enumerator4829@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      1
      ·
      15 hours 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.

    • swab148@lemm.ee
      link
      fedilink
      arrow-up
      24
      ·
      22 hours 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
            3
            ·
            5 hours 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.