‹ BackHN Continuity

Thread

Btrfs/ZFS/bcachefs under workloads classic benchmarks skip

179 points · 190 comments · farlight

  1. skerit · · focus · HN ↗
    Oh, so bcachefs is doing pretty well.
    1. tarruda · · focus · HN ↗
      Except for the fact that the developer has sabotaged the project into being removed from mainline?
      1. irusensei · · focus · HN ↗
        That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers.

        In fact they delivered the erasure coding for parity raid back in march this year.

        The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is. I can only tell you that mixing different device tiers and having a per-file/directory replication setting is a god send specially in these times where storage costs more than gold.

        1. novafunc · · focus · HN ↗
          bcachefs was already working at its own pace prior to being accepted in the kernel. It could have continued doing so for years until it was really "ready".

          Instead it got kicked out because Kent constantly ignored the kernel's contribution rules and is unlikely it will ever be accepted back into the kernel.

          1. koverstreet · · focus · HN ↗
            I'd really appreciate it if we could drop the FUD over contribution rules. There are no such rules, it is explicitly Linus's way or the highway, and I already replied to that elsewhere.

            And it went in when it did because Redhat was pushing for it and claiming to be supportive - but that never materialized. They wanted to get something for free without investing, or putting in the absolute bare minimum.

            A _lot_ of people were saying publicly and privately "dear god yes we need something better than btrfs" - but no one from the existing kernel community was interested in stepping up.

            Community's still growing, though. A lot of people have gotten active in making sure bcachefs actually works well for people end to end, and there's a hell of a lot more to shipping a filesystem than just writing kernel code.

            1. pantalaimon · · focus · HN ↗
              You can't let Reddit guide your technical decisions.

              The FS was marked experimental, so there is no urgency in fixing bugs or providing features in a certain cycle. Everyone using it knows what they got themselves into. You can still provide the DKMS module for faster fixes and features for anyone who wants to use BCacheFS more seriously for the time that the upstreaming process takes, but eventually it would have all been on mainline.

              Asahi is taking a similar approach where they have their downstream kernel and push things upstream once they are mature.

              That means the upstream kernel is not useful for running on that hardware now, but things are moving there eventually.

              1. koverstreet · · focus · HN ↗
                No urgency over fixing bugs? What do you think this is, btrfs? :)

                All this has been discussed to death, we don't need people armchair quarterbacking a year later. It's over, it's time to move on.

            2. tosti · · focus · HN ↗

              [dead]

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.