Hello everyone. I’m going to build a new PC soon and I’m trying to maximize its reliability all I can. I’m using Debian Bookworm. I have a 1TB M2 SSD to boot on and a 4TB SATA SSD for storage. My goal is for the computer to last at least 10 years. It’s for personal use and work, playing games, making games, programming, drawing, 3d modelling etc.

I’ve been reading on filesystems and it seems like the best ones to preserve data if anything is lost or corrupted or went through a power outage are BTRFS and ZFS. However I’ve also read they have stability issues, unlike Ext4. It seems like a tradeoff then?

I’ve read that most of BTRFS’s stability issues come from trying to do RAID5/6 on it, which I’ll never do. Is everything else good enough? ZFS’s stability issues seem to mostly come from it having out-of-tree kernel modules, but how much of a problem is this in real-life use?

So far I’ve been thinking of using BTRFS for the boot drive and ZFS for the storage drive. But maybe it’s better to use BTRFS for both? I’ll of course keep backups but I would still like to ensure I’ll have to deal with stuff breaking as little as possible.

Thank you in advance for the advice.

  • MasterBlaster@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    Systems like DSM from synology have integrity scrubbing to fight bit rot. Run it once a quarter on a 4 drive, and you’re protected. Plus, you should be backing up your data, even with RAID.

    BTRFS, last I read, had lots of complexity and weird problems. Hopefully, it has improved since then (about 3 years ago).

    • turdas@suppo.fi
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      Btrfs can be a little complex and needs more user-friendly tooling for some of the advanced features to be useful to “laymen”, but OP seems technical enough (the fact that he cares about what filesystem he’s running in the first place is an indicator of this) that this should not be an issue.

      As for “weird problems”, the majority of those seems to come down to users using advanced features without RTFM, and users having underlying system issues that cause issues that btrfs catches early and refuses to mount the filesystem as RW, and the users then blame btrfs for the issue.

      • mimichuu_@lemm.eeOP
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I don’t mind needing to be technical or having to read to do things right. I probably wont really do much fancy things, I just don’t want the filesystems dying on me out of nowhere. If they’re stable enough for that, that’s enough for me. Thanks for the help

        • turdas@suppo.fi
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          The two things I would recommend to any btrfs user is enabling zstd compression and setting up automatic snapshots using snapper or Timeshift. I would personally recommend snapper if you’re comfortable with command-line tools, as Timeshift only supports a very specific configuration.

          zstd compression is very fast, so if you have a reasonably new CPU you will notice no overhead from it, making it effectively just free extra disk space.

          Snapshots require a little bit of reading to understand, particularly because you will want a very specific subvolume layout to sensibly organize them, and distro installation wizards rarely give you such a layout except on distros that support snapshots out of the box, like OpenSUSE.

          The Arch wiki page on btrfs is amazingly good, as is their page on snapper if you want to set up snapshots.

    • ebits21
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 year ago

      DSM uses btrfs? It’s actually quite solid.

      • MasterBlaster@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I’m aware. I considered using it when I upgraded the hardware. Good to hear it is solid. If that is the consensus, I might switch, eventually.