• tony@lemmy.hoyle.me.uk
    26·
    1 year ago

    What I’ve read looks good but it’s going to need a track record of reliability before I’d trust it.

    • woelkchen@lemmy.world
      361·
      1 year ago

      it’s going to need a track record of reliability before I’d trust it.

      That’s why kernel inclusion is so important: People can start testing it without jumping through hoops of manually patching and compiling the kernel.

    • nachtigall@feddit.deEnglish
      14·
      1 year ago

      Curious too. I tried running bcachefs last year and with the combination of compression and encryption everything ended up corrupted very very fast.

  • AggressivelyPassive@feddit.de
    201·
    1 year ago

    I only read the wiki article and honestly, I can’t tell what makes that different from other “advanced” FSs like BTRFS and ZFS.

    Could someone get me up to speed here?

    • Spore@lemmy.ml
      33·
      1 year ago

      Compared to btrfs it’s claimed to be faster and having working RAID support. Its unique feature is using a fast device as cache to speed up access to slower, larger disks, I think.

      • trougnouf@lemmy.worldOP
        13·
        1 year ago

        Yes. The intelligent multi-device-type feature is a huge improvement for any workload that needs more space than what an SSD can affordably provide, even moreso with the reliability of eg RAID1.

        Before that I had to use BTRFS (RAID1) on bcache (not fs) devices, but half of the cache space was being wasted on the redundant copies because the two systems operate independently.

        • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.social
          16·
          1 year ago

          To explain in case someone doesn’t know what this means, it’s something BTRFS doesn’t have (and AFAIK isn’t even on the roadmap). It means you could have, say, an SSD and a more reliable HDD RAIDed such that every stripe on the HDD counts as multiple writes; and you might set that system up so that the SSD is read with priority, and the HDD is written in the background, so that - even though you have a slow drive in the RAID, throughput happens at the faster SSD speeds.

          The average user probably won’t use this much, but there are all sorts of ways this could be leveraged, by companies, self-hosters, smart OS installation scripts, even removable drive mounters, like udiskie.

      • intrepid@lemmy.ca
        7·
        1 year ago

        Compared to btrfs, it has native encryption too - though it’s said to be unaudited at the moment. Btrfs needs dmcrypt for encryption support.

        • Tiuku@sopuli.xyz
          1·
          1 year ago

          What are the actual differences between native encryption and dmcrypt? Like: Can it be booted? Does it leak more information about the fs? Is it faster?

          • intrepid@lemmy.ca
            4·
            1 year ago

            Native encryption is when the filesystem driver does the decryption in addition to the regular decoding job. Dmcrypt is where encryption is done by a separate component that’s part of the kernel. Dmcrypt decrypts the raw block device (partition) and creates an unencrypted virtual block device (usually in /dev/mapper/). The filesystem driver then decodes this virtual device to give the final data access. It’s like having a filesystem within a filesystem.

            Regular bootloaders like Grub can’t decrypt anything. So the /boot device is usually on a separate unencrypted partition. You need the initramfs to be able to decrypt and decode the partition. That’s not very complicated - most users don’t even need to deal with it.

            Dmcrypt is arguably more secure than native encryption, since you won’t know the filesystem type until you decrypt the partition first. On the other hand, native encryption is likely to be faster and more flexible for complex filesystems like ZFS, Btrfs and BCachefs.

    • ikidd@lemmy.worldEnglish
      5·
      1 year ago

      Compared to ZFS, it’s a sideways movement except for being in the kernel. ZFS has a lot more enterprise level features and an excellent track record. Its used widely for some pretty big installations, and still can be used by the homelabber quite nicely. Things like fs send and native encryption are big.

      Compared to BTRFS, well, it’s definitely an improvement in many areas for a driver that’s in the kernel.

      • LaLiLuLuCo@lemmy.ca
        2·
        1 year ago

        I don’t know of anything that documents it as well as reading the literal mailing list responses at each time it became relevant.

        But the actual development story isn’t that interesting other than when some extremely unprofessional behavior from a lot of parties occurred.

      • massive_bereavement@kbin.social
        1·
        1 year ago

        Sorry, I don’t know if it is documented anywhere, but in summary the project started with bcache (block cache) from a single developer (Kent Overstreet A.K.A Evil Pie Pirate) in 2010 that explained he was building a module for the Linux Kernel.

        Bcache is a method of using a fast ssd drive as a caching mechanism for slow but large hdds. As is, the project was quite ambitious but then, when the developer was working in an evolution of bcache (kind-of lessons learned re-implementation), the project grew into a general-purpose POSIX filesystem.

        Considering the origins of the most popular file system implementations, expecting a single individual being successful creating a general-purpose one sounded over ambitious.

        Then in 2013, out of the blue, Kent left Google to solely work in this project. (In reality though, he spent two years later in Datera as well.)

        Then, how do you finance a single developer for a file system from 2013 onwards up to today, when it finally merged into the kernel?

        Patreon. The whole thing was financed through it.

        That said, there are other collaborators like Daniel Hill, Dave Chinner or Brian Foster, yet what’s surprising is how this started as a side project and eventually became the main competitor of corporate-developed file systems by Patreon funding.

        Note: A bit of hype-control here, btrfs which would be the main “competitor” was merged into kernel 14 years ago, so bcachefs still has a long way to go before we can trust it with our data.

  • mindlight@lemm.ee
    164·
    1 year ago

    Does Bcachefs come with any guarantees regarding my wife’s wellbeing?

    If not, I’m definitively sticking with my OpenZFS.

  • Tobu@lemmy.ml
    9·
    1 year ago

    Happy happy joy! I’ve been using it for a year already, as it is simpler to manage than luks + lvm + bcache + whatever FS.

    It has been entirely unproblematic through frequent kernel upgrades; caching, background compression and encryption just work.

    I’m very glad it made it in; it deserves wider adoption.