‹ BackHN Continuity

Thread

Btrfs/ZFS/bcachefs under workloads classic benchmarks skip

179 points · 190 comments · farlight

  1. blop · · focus · HN ↗
    I think the reviews should also include the social aspect of these filesystems...

    There is and have been many promising and exciting FS to replace the old boring ones, but for storage you not only want to avoid technical issues but also maintainer(s) drama...

    1. koverstreet · · focus · HN ↗
      Why do people keep bringing up drama?

      The community infighting has sucked, but that's a thing that matters primarily for maintainers.

      I think most users just want something that works.

      1. blop · · focus · HN ↗
        drama matters because most users don't want to have their favourite FS randomly removed from the kernel unexpectedly after some OS update :)

        That said I certainly hope that one day the technical advantage of bcachefs will be so overwhelming that maybe the decision to remove it will be overturned. And if big vendors make it their default FS the bus factor will disappear (even if unofficially you'd still be the sole maintainer, but no one cares about that in the enterprise world...)

        1. rleigh · · focus · HN ↗
          > most users don't want to have their favourite FS randomly removed from the kernel

          True. But when you look at this, isn't the deeper problem that Linux remains such a monolith, and there's a stark difference between "included" and "not included" in the kernel. It's now over 35 years old. The fact that we can't have stable APIs and develop more out-of-tree drivers is not a strength, it's a weakness.

          Even old Unix systems like SVR4 managed to have stable, public driver interfaces, despite being rather proprietary. FreeBSD manages to have drivers in its ports tree, with a stable API for a given major version. What makes Linux so special that it can't manage this?

          I understand all of the arguments about why this has to be so. But... they might have made sense in the early days, but after 35 years it screams of immaturity. Plenty of other systems, including other open source systems, manage to do this, including having versioned interfaces so things aren't set in stone. Linux remains right at the extreme end of guaranteeing nothing. I've long thought this was unnecessary and counterproductive.

          1. em-bee · · focus · HN ↗
            the downside of a stable API is more non-free drivers. the API being unstable is a strength in that it forces driver developers to use a GPL compatible license in order to get their drivers into the kernel, or it motivates the FOSS community to develop alternative drivers that are GPL compatible.

            and, i believe i read somewhere that this is not an inability to stabilize the API but a conscious decision to not promise a stable API expressly because it creates the effect i described.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.