Thread

Btrfs/ZFS/bcachefs under workloads classic benchmarks skip

179 points · 190 comments · farlight

blop · 1789845579 · 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 · 1789847441 · 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. Skunkleton · 1789847853 · focus · HN ↗
    Related username?
    To answer the original question, most people who care about their filesystem at all care about its stability. Not just "does it work now" but also "will it work and improve over time". Infighting puts the future at risk.
    koverstreet · 1789848382 · focus · HN ↗
    It really does.
    But you might want to check out the bus factor on btrfs too; when a maintainer says "but we've saved Facebook billions and billions of dollars!", calls for the other filesystem maintainer to be ejected from the community, then quits to join Anthropic a month later - that's not a vote of confidence.
    I'd be very happy if people could just stop bringing up drama and us factors. We put it behind us a year ago, but it seems not everyone got the memo.
    nolist_policy · 1789888554 · focus · HN ↗
    Checking the bus factor:
    Btrfs regulars:
    - 1 from Meta
    - 1 from Oracle
    - 4 from SuSe
    - 2 from WDC
    bcachefs:
    - Kent Overstreet
    r0l1 · 1789893192 · focus · HN ↗
    Might end in a new bcachefs fork beeing included back into mainline. If companies sponsor a few fulltime devs working on the new fork, we finally might have a stable enterprise ready CoW filesystem.
    koverstreet · 1789911219 · focus · HN ↗
    Uhh, do you know what the upstream stance is on testing and fixing bugs?
    I doubt there'd be any real interest in a bastardized fork that only exists so the deep pocketed vendors can get away with code dump and run.
    r0l1 · 1790023913 · focus · HN ↗
    Thought about a real fork going in its own direction. I would love to use bcachefs in all our products. But the current state does not qualify for usage within enterprise environments. Any ideas how to get that fixed? How many core developers are present? Any fallback plans, ...? How to help to get there?
    throw0101a · 1789903157 · focus · HN ↗
    And Btrfs still does not have a RAID-5/6 that they themselves recommend for usage:
    * <a href="https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#man-btrfs5-raid56-status" rel="nofollow">https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#man-b...
    What have they been doing for the last decade(+)?
    farlight · 1789906633 · focus · HN ↗
    Other things: since no companies sponsoring its development had any interest in raid 5/6, which is mostly a home enthusiast thing.
    Western Digital picked up this work last year and is slowly getting through the new design without the write hole, I think we'll see working raid 5/6 in the next year or two.
    throw0101a · 1789911785 · focus · HN ↗
    > Other things: since no companies sponsoring its development had any interest in raid 5/6, which is mostly a home enthusiast thing.
    I've used RAID-Z1/2/3 at a couple of jobs: yes IOps is suck-y, but if it's for backups of other systems, or the central logging server, or network monitoring (Suricata, Snort), sometimes your priority is cheap/bulk.
    I'm currently in the HPC space, and Lustre is a thing here, and it has tiered storage via policies: you can (e.g.) put your recent/hot data on NVMe, but older/colder bits on spinning rust on ZFS.
  2. throwaway85825 · 1789850381 · focus · HN ↗
    I don't care about the drama, I just want to say thank you for your continued work to advance the state of the art in open file systems.
    koverstreet · 1789851097 · focus · HN ↗
    Appreciate it :)
  3. blop · 1789855817 · 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...)
    rleigh · 1789896967 · 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.
    em-bee · 1789947187 · 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.
    throw0101a · 1789903011 · 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 :)
    Jokes on you then: my favourite FS can't be "randomly removed from the kernel unexpectedly after some OS update" because it never made it in — ZFS. :)

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.