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

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

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

    Kent Overstreet who has been developing the Bcachefs out of the BCache code has announced core feature work has wrapped up, he's very happy with how the work has panned out, and potentially could be merging the code into the Linux kernel soon if the review is pleasant...

    http://www.phoronix.com/scan.php?pag...-Features-Done

  • cthart
    replied
    Originally posted by DrYak View Post
    ... bits that were missing from BcacheFS ...
    I hope it's never missing any bits :-) :-)

    Leave a comment:


  • profoundWHALE
    replied
    Originally posted by gorgone View Post
    omg not another one ....
    It's not really 'new' more like a version 2. It takes bcache and uses that for the file-system, avoiding the issues that btrfs has (bugs bugs bugs)

    Leave a comment:


  • Volta
    replied
    Originally posted by ermo View Post
    I think the review thread on LKML is interesting mainly because (AIUI) Dave Chinner is telling Linus that a specific piece of (supposedly generic) kernel code for managing locks is broken enough that it's caused the xfs devs so much pain that Dave refuses to rely on it, while Linus wants it to be stress-tested and stabilised.

    One could easily be led to suspect that perhaps the Linux kernel is -- to paraphrase the inimitable Eddie Izzard -- being held together by string, duct-tape and a note from Linus' mother.
    When you're quoting someone do it well. He said there were bugs in generic locking code in the past not in the XFS. What seems to be broken is your ability to read.

    Leave a comment:


  • geearf
    replied
    As far as I know the problematic code has been found and a quick patch has already been written to prove it's fixable.
    I'm not aware of the proper fix being done yet.

    Leave a comment:


  • geearf
    replied
    Originally posted by DrYak View Post

    That's why, before merging any new filesystem into the kernel, a sponsorship from a company is required.
    If Kent drops the ball and moves onto something else, the company relying upon BcacheFS can pay another dev (or a few) to do maintenance.

    (see BTRFS and Oracle/Facebook/SUSE).

    Kent has found a company sponsoring BcacheFS (they use it on NAS boxes), and that company apparently is insisting on him finishing a few key features (extrefs, which will lead to CoW snapshots - though not necessarily before merging)
    Sponsorship would be great indeed, but having more than one person knowledgeable should also happen before inclusion I think (or at least before leaving staging if it starts there).
    The promise of support is great, but if it takes 6 months for the new dev to get up to speed before low level yet important bugs can be fixed...

    It is awesome that a company is sponsoring him already, I had no idea.
    Thank you for the link, I'll read into it right away.

    Leave a comment:


  • DrYak
    replied
    Originally posted by geearf View Post
    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.
    That's why, before merging any new filesystem into the kernel, a sponsorship from a company is required.
    If Kent drops the ball and moves onto something else, the company relying upon BcacheFS can pay another dev (or a few) to do maintenance.

    (see BTRFS and Oracle/Facebook/SUSE).

    Kent has found a company sponsoring BcacheFS (they use it on NAS boxes), and that company apparently is insisting on him finishing a few key features (extrefs, which will lead to CoW snapshots - though not necessarily before merging)

    Leave a comment:


  • AsuMagic
    replied
    bcache bug, does this affect the out-of-tree bcachefs or not?

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by mmstick View Post

    Honestly, I doubt there's any measurable difference. Placing drivers in the kernel doesn't magically make them faster, either.
    No but without a microkernel you are capped on performance if you aren't doing stuff in-kernel.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by mmstick View Post
    Honestly, I'd rather that we move all file system drivers to user space.
    Linux isn't a microkernel, it won't go well.

    Leave a comment:

Working...
X