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

[cthart]

... bits that were missing from BcacheFS ...

I hope it's never missing any bits :-) :-)

[profoundWHALE]

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)

[Volta]

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.

[geearf]

have they fixed this bug yet?

https://www.phoronix.com/scan.php?page=news_item&px=BCache-Corruption-Linux-5

https://www.phoronix.com/scan.php?pa...Corruption-Hit

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.

[geearf]

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.

[DrYak]

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)

[AsuMagic]

have they fixed this bug yet?

https://www.phoronix.com/scan.php?pa...uption-Linux-5
https://www.phoronix.com/scan.php?pa...Corruption-Hit

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

[starshipeleven]

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.

[starshipeleven]

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

Linux isn't a microkernel, it won't go well.

[[email protected]]

Wasn't the functionality of bcache merged in with bcachefs?

https://bcachefs.org/ ： “Caching” - with SSD?