kernel/git/torvalds/linux.git - Linux kernel source tree
git.kernel.org
      • massive_bereavement@kbin.social
        2·
        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.

      • 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.

        Like actual piss baby anti social nerd shit.

  • mindlight@lemm.ee
    163·
    1 year ago

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

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

  • tony@lemmy.hoyle.me.uk
    11·
    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.

  • 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.

  • AggressivelyPassive@feddit.de
    8·
    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
      16·
      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.

      • intrepid@lemmy.ca
        8·
        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.