• stealthnerd@lemmy.world
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    11 months ago

    I’m really excited for this. If it lives up to the hype I think it could become the defacto filesystem some day.

    BTRFS, despite being a great filesystem, got a bad rep mostly due to its poor RAID5/6 implementation. It also lags behind in performance in many configurations and has been mostly relagated to a specialty filesystem. While it could make a great root filesystem few distros have adopted it as such.

    ZFS has been similarly pigeon holed. It’s typically only used for building large arrays because it’s not very safe when used on a single device. It also lacks a lot of the flexibility of BTRFS, though you could say it trades flexibility for reliability.

    bcachesfs on the other hand feels like it has the potential to be adopted as a root file system while also providing replication, erasure coding, high performance and snapshots; something that no filesystem has managed to date, at least on a wide scale.

  • geoff@lemm.ee
    link
    fedilink
    arrow-up
    7
    ·
    11 months ago

    I’m a happy btrfs user, but it’s most definitely a great thing to see what seems like a really clean implementation like this that is able to learn from the many years of collective experience with ZFS and btrfs.

  • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.one
    link
    fedilink
    arrow-up
    6
    ·
    11 months ago

    Built-in encryption in bcachefs sounds great, that’s the only thing that BTRFS has been missing for me so far.

    Bonus points if it can be decrypted on boot like LUKS, and double bonus points if its scriptable like cryptsetup (retrieve key from hardware device, or network, or flash stick etc)

    https://bcachefs.org/Encryption/

    Will likely give bcachefs a spin as soon as it drops in Debian Unstable 😁

      • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.one
        link
        fedilink
        arrow-up
        1
        ·
        11 months ago

        Yeppp this is what I currently do, and offers the best performance IMO compared to using something like gocryptfs in userspace on top of BTRFS. Pretty happy with it except a few small things…

        It can be a bit of a faff to mount on a new machine if its file manager doesn’t support encrypted volumes natively ☹️. On your daily you can have it all sorted in your crypttab and fstab so it’s not an issue there

        My main problem though is if it’s an external USB device you have encrypted with LUKS, the handles and devices stay there after an unexpected USB disconnect… so you can’t actually unmount or remount the dm-crypt device after that happens. Anytime you try, the kernel blocks you saying the device is busy - only fix i’m aware of is a reboot.

        If the encryption is managed by the filesystem itself, one would probably assume this kind of mounting & unexpected disconnect scenario would be handled as gracefully as possible

        • ReversalHatchery@beehaw.org
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          11 months ago

          I see, good points.

          I have also experienced that dangling devices break remounting it, but I think there’s a quicker solution for it: dmsetup remove insert_device_name_here.
          It’s still a manual thing, though, but 2 steps better. Maybe it can be automated somehow, I haven’t looked into that yet.

  • chunkyhairball@lemmy.ml
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    11 months ago

    I’m always nervous when hearing about new filesystems since a certain high profile news incident a several years back.

    I really, really, really hope that Kent Overstreet has a really good relationship with any partner or spouse he may or may not have.