Announcement

Collapse
No announcement yet.

Bcachefs Completes Core Feature Work, Could Merge Soon If Review Goes Well

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • DoMiNeLa10
    replied
    Originally posted by bitman View Post

    Now that would perform real fast. Not.
    There would be no discussion about this if we would be using microkernels.

    Leave a comment:


  • DrYak
    replied
    (oops, my message #6 in this thread got "Unapproved" :-( )

    Leave a comment:


  • Britoid
    replied
    Originally posted by geearf View Post
    That's great news!
    Yet I am concerned that Kent may abandon this project eventually like he did with bcache, so before a merge we might need a few devs with full understanding of the codebase.
    Wasn't the functionality of bcache merged in with bcachefs?

    Leave a comment:


  • geearf
    replied
    That's great news!
    Yet I am concerned that Kent may abandon this project eventually like he did with bcache, so before a merge we might need a few devs with full understanding of the codebase.

    Leave a comment:


  • DrYak
    replied
    (and overall, a "tiered" storage solution is a much more elegant solution to the write hole. Shame that BTRFS doesn't have a similar concept yet, tough the auto-balance part is the first baby step along this path).

    Leave a comment:


  • DrYak
    replied
    The interesting part of this story, for me, is that the bits that were missing from BcacheFS are finally going to be implemented:

    - erasure coding (which thanks to the "tiered" storage approach of BcacheFS (and its Bcache origin) means that it's actually possible to do it *without* any possible write hole - exactly what I've been missing from current BTRFS) (According to Kent, it's
    - reflinking (and thus eventually CoW snapshotting) is a hard-requirement from the company sponsoring (the thing I currently love in BTRFS and would never consider BcacheFS without it)

    Now let's hope:
    - Kent actually finishes these two bits (mailling says he would consider merging before these two are finished. Please let it not be another "BTRFS' RAID56 is (still) not officially considered stable" situation. I hope that eventually these two get officially stable in BcacheFS, even if Kent manage to get merged before).
    - Massive large scale testing. I hope that over the next couple of years, most bugs will eventually be ironed out. (see Facebook testing BTRFS as an example. The stable features of BTRFS *are* stable)
    - At least some major distro starts considering it as a default and pours the necessary resources to keep BcacheFS at top notch quality (see openSUSE and BTRFS).

    And in a couple of years down the line, BcacheFS might eventually become decent competition to BTRFS. (wiith an actual compatible license. ZFS, I'm looking at you !)

    (Oh, yeah, and a compression that actually saves space would be a nice touch, too...)

    Leave a comment:


  • bitman
    replied
    Originally posted by mmstick View Post
    Honestly, I'd rather that we move all file system drivers to user space.
    Now that would perform real fast. Not.

    Leave a comment:


  • mmstick
    replied
    Honestly, I'd rather that we move all file system drivers to user space.

    Leave a comment:


  • Britoid
    replied
    I hope this thing succeeds, it looks like a really good filesystem.

    Leave a comment:


  • gorgone
    replied
    omg not another one ....

    Leave a comment:

Working...
X