There’s been some Friday night kernel drama on the Linux kernel mailing list… Linus Torvalds has expressed regrets for merging the Bcachefs file-system and an ensuing back-and-forth between the file-system maintainer.

  • solrize@lemmy.world
    link
    fedilink
    arrow-up
    47
    ·
    26 days ago

    Can someone say why bcachefs is interesting? Btrfs I can sort of understand. I haven’t much kept track of most others.

    • DaPorkchop_@lemmy.ml
      link
      fedilink
      arrow-up
      73
      ·
      26 days ago

      bcachefs is way more flexible than btrfs on multi-device filesystems. You can group storage devices together based on performance/capacity/whatever else, and then do funky things like assigning a group of SSDs as a write-through/write-back cache for a bigger array of HDDs. You can also configure a ton of properties for individual files or directories, including the cache+main storage group, amount of data replicas, compression type, and quite a bit more.

      So you could have two files in the same folder, one of them stored compressed on an array of HDDs in RAID10 and the other one stored on a different array of HDDs uncompressed in RAID5 with a write-back SSD cache, and wouldn’t have to fiddle around with multiple filesystems and bind mounts - everything can be configured by simply setting xattr values. You could even have a third file which is striped across both groups of HDDs without having to partition them up.

      • NeoNachtwaechter@lemmy.world
        link
        fedilink
        arrow-up
        13
        arrow-down
        5
        ·
        26 days ago

        two files in the same folder, one of them stored compressed on an array of HDDs in RAID10 and the other one stored on a different array […]

        Now that’s what I call serious over-engineering.

        Who in the world wants to use that?

        And does that developer maybe have some spare time? /s

        • apt_install_coffee@lemmy.ml
          link
          fedilink
          arrow-up
          31
          ·
          26 days ago

          This is actually a feature that enterprise SAN solutions have had for a while, being able choose your level of redundancy & performance at a file level is extremely useful for minimising downtime and not replicating ephemeral data.

          Most filesystem features are not for the average user who has their data replicated in a cloud service; they’re for businesses where this flexibility saves a lot of money.

          • apt_install_coffee@lemmy.ml
            link
            fedilink
            arrow-up
            2
            ·
            24 days ago

            I’ll also tac on that when you use cloud storage, what do you think your stuff is stored on at the end of the day? Sure as shit not Bcachefs yet, but it’s more likely than not on some netapp appliance for the same features that Bcachefs is developing.

        • Semperverus@lemmy.world
          link
          fedilink
          English
          arrow-up
          7
          arrow-down
          1
          ·
          26 days ago

          This probably meets some extreme corporate usecase where they are serving millions of customers.

          • DaPorkchop_@lemmy.ml
            link
            fedilink
            arrow-up
            13
            ·
            edit-2
            26 days ago

            It’s not that obscure - I had a use case a while back where I had multiple rocksdb instances running on the same machine and wanted each of them to store their WAL only on SSD storage with compression and have the main tables be stored uncompressed on an HDD array with write-through SSD cache (ideally using the same set of SSDs for cost). I eventually did it, but it required partitioning the SSDs in half, using one half for a bcache (not bcachefs) in front of the HDDs and then using the other half of the SSDs to create a compressed filesystem which I then created subdirectories on and bind mounted each into the corresponding rocksdb database.

            Yes, it works, but it’s also ugly as sin and the SSD allocation between the cache and the WAL storage is also fixed (I’d like to use as much space as possible for caching). This would be just a few simple commands using bcachefs, and would also be completely transparent once configured (no messing around with dozens of fstab entries or bind mounts).

    • nous@programming.dev
      link
      fedilink
      English
      arrow-up
      16
      ·
      26 days ago

      bcachefs is meant to be more reliable than btrfs - which has had issues with since it was released (especially in the early days). Though bcachefs has yet to be proven at scale that it can beat btrfs at that.

      Bcachefs also supports more features I believe - like encryption. No need for an extra layer below the filesystem to get the benefits of encryption. Much like compression that also happens on both btrfs and bcachefs.

      Btrfs also has issues with certain raid configurations, I don’t think it yet has support for raid 5/6 like setup and it has promised that for - um, well maybe a decade already? and I still have not heard any signs of it making any progress on that front. Though bcachefs also still has this on their wishlist - but I see more hope for them getting it before btrfs which seems to have given up on that feature.

      Bcachefs also claims to have a cleaner codebase than btrfs.

      Though bcachefs is still very new so we will see how true some of its claims will end up being. But if true it does seem like the more interesting filesystem overall.

    • ikidd@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      26 days ago

      Also because it’s meant to be an enterprise level filesystem like ZFS, but without the licensing baggage. They share a lot of feature sets.

    • apt_install_coffee@lemmy.ml
      link
      fedilink
      arrow-up
      6
      ·
      26 days ago

      In addition to the comment on the mentioned better hardware flexibility, I’ve seen really interesting features like defining compression & deduplication in a granular way, even to the point of having a compression algo when you first write data, and then a different more expensive one when your computer is idle.