3 ms·

BCacheFS is the best Linux filesystem now that storage costs a premium. You can mix devices of different sizes and types on bcachefs. You can have foreground a

BCacheFS is the best Linux filesystem now that storage costs a premium. You can mix devices of different sizes and types on bcachefs. You can have foreground and background devices to balance performance and also different compression settings for foreground and background transactions. You can set replicas=N to the individual file or directory on bcachefs. For example files you can just re-download or re-build. Likewise you can set a higher number of copies to important files.

suncore 15d ago
Sure, when it's mature...
- mkeedlinger 15d ago
  Yeah, and I think Overstreet might be going hard on AI, so not sure how that might effect the project
  - koverstreet 15d ago
    If you have "refine until it's perfect and don't screw with things you don't understand" thoroughly ingrained, along with the dangers of overconfidence, you'll do fine with AI. Not everyone gets it though, that's for sure. And, if you want to know if it's mature, I'd trust the user reports over the one liners :)
lukaslalinsky 15d ago
I've been using ZFS on my Linux servers for years and have pretty good experience with it. I've not been following Linux development too much. Is bcachefs usable/stable/reliable enough to replace it?
- khajdamowicz 15d ago
  It's not as battle-tested like ZFS with 15+ years of field usage, but it's good enough for me and other users. There's a NAS appliance called NASty and it shares publicly usage stats: https://nasty-telemetry.pages.dev/ https://nasty-telemetry.pages.dev/ Those numbers are NASty alone. There are more users on other systems.
  - cromka 15d ago
    15+ years of ZFS code is also often said as being a nearly unmanageable pile of mess, supposedly to the point that there’s some of the code that maintainers are afraid of touching, and with plenty of unresolved weird bugs (which I experienced myself with data loss). Sometimes starting fresh with one coherent codebase and all features design baked in from the start might be better.
    - lukaslalinsky 14d ago
      It takes 10+ years for any storage engine to iron out all the wrinkles, get it to a state where it's both fast enough, and you can trust it to not lose data. It's stupid to throw it away once it reaches that point.
      - cromka 14d ago
        It's not stupid if the 10+ years code is unmaintainable. Why did you ignore that part?
      - koverstreet 14d ago
        People keep saying it takes 10 years, but that presupposes methods that never improve. Why would we keep doing the same thing over and over again? Wouldn't be much point in that.

suncore 15d ago

Sure, when it's mature...

mkeedlinger 15d ago
Yeah, and I think Overstreet might be going hard on AI, so not sure how that might effect the project
- koverstreet 15d ago
  If you have "refine until it's perfect and don't screw with things you don't understand" thoroughly ingrained, along with the dangers of overconfidence, you'll do fine with AI. Not everyone gets it though, that's for sure. And, if you want to know if it's mature, I'd trust the user reports over the one liners :)

lukaslalinsky 15d ago

I've been using ZFS on my Linux servers for years and have pretty good experience with it. I've not been following Linux development too much. Is bcachefs usable/stable/reliable enough to replace it?

khajdamowicz 15d ago
It's not as battle-tested like ZFS with 15+ years of field usage, but it's good enough for me and other users. There's a NAS appliance called NASty and it shares publicly usage stats: https://nasty-telemetry.pages.dev/ https://nasty-telemetry.pages.dev/ Those numbers are NASty alone. There are more users on other systems.
- cromka 15d ago
  15+ years of ZFS code is also often said as being a nearly unmanageable pile of mess, supposedly to the point that there’s some of the code that maintainers are afraid of touching, and with plenty of unresolved weird bugs (which I experienced myself with data loss). Sometimes starting fresh with one coherent codebase and all features design baked in from the start might be better.
  - lukaslalinsky 14d ago
    It takes 10+ years for any storage engine to iron out all the wrinkles, get it to a state where it's both fast enough, and you can trust it to not lose data. It's stupid to throw it away once it reaches that point.
    - cromka 14d ago
      It's not stupid if the 10+ years code is unmaintainable. Why did you ignore that part?
    - koverstreet 14d ago
      People keep saying it takes 10 years, but that presupposes methods that never improve. Why would we keep doing the same thing over and over again? Wouldn't be much point in that.