It's Looking Like Bcachefs Won't Be Merged For Linux 6.5

[Quackdoc]

Would you like to explain? I'm interested in that no code part of software development...

devs all have their own problem solving capabilities and directions, especially highly skilled devs like the ones in question. there are often many correct ways to solve a problem, and those methods often clash, and the more experienced the developer the stronger those ideas often are, and when strong ideas clash against each other, you get this. it happens fairly often, it just so happens that the LKML is a public forum with little moderation outside of self moderation, and is relatively "unprofessional" (though I think that's actually beneficial in the end). this happens not often, but not rare either. and the lkml is certainly not alone in ecosystems like this.

the difference here is, grown adults should be able to at least get the technical bits done despite differences. and jumping on someone then lying saying you didn't when it's on a public forum is shameful. letting your spats get in the way of technical discussion, dancing around issues and dog piling, are NOT part of what we want. but in the end, developers are still human, and developers in general tend to be a bit more solid in stance then other professional folk.

[ravenpi]

My ignorant ass had to read that three times to get the joke. Dafuq is a B.C.A. chef?

I'm guessing BCA chefs is autocorrect "helping" him spell BcacheFS.

[F.Ultra]

Nobody's perfect. Hens Reiser was an asshole before killing his wife and he was able to get merged his filesystem. Kent is doing *A LOT* of work and maybe sees too much conservative resistance in Linux kernel development?

He was, but he also employed a staff of programmers that wasn't and I'm not so sure that it had been merged if Hans had been the sole contact, aka kernel devs could work with his employees and just outright ignore Hans.

Am I too stupid to understand Bcachefs is vaporware and not so good compared to other filesystems such as Btrfs and ZFS or what?

No, but I think the misconception here is that this have to do with the quality of Bcachefs. It doesn't, Bcachefs could be the best thing ever and it still won't be merged unless the kernel devs (unless Linus steps in) are satisfied that it will be properly maintained for a long future. And with "properly" it also means that whoever maintains it will be open to later changes when other systems demand it and here the problem of the personality of the sole developer comes in.

Now it seems like Kent is receiving a lot of unnecessary flack from the kernel devs, and I have not followed it all thoroughly,but one have to understand when reading those that there is history here, history that goes back beyond these recent patches.

The thing is though that this is the initial inclusion attempt, code extremely seldom gets included on the first try. Contrary to what many believe, the responsibility of the kernel devs is not to accept code but to reject code, aka the default mode is to look for problems.

[ravenpi]

[QUOTE=timofonic;n1397156]

Nobody's perfect. Hens Reiser was an asshole before killing his wife and he was able to get merged his filesystem. Kent is doing *A LOT* of work and maybe sees too much conservative resistance in Linux kernel development?

This is not really the case. (If I quoted this incorrectly, please apologize; I've not done much stuff on Phoronix.) Hans had ReiserFS _3_ merged, and that was before his bdeing an a-hole really showed. It was when he tried to get Reiser4 merged -- basically, as one large blob -- and refused to play ball with Linus that he really showed his colors, and was told "Break into manageable, reviewable parts, or GTFO." And that's why Reiser4 was never merged into the kernel. The murder and imprisonment happened when this was really more-or-less a given.

[kreijack]

What so evil about that non-bcachefs stuff? Are they abusing some developer while doing it? Are they afraid of change? Does it improve these parts or not?

My understand is that beside the technical aspect, nobody started to merge these "non-bcachefs" stuff. If I understood correctly, the general request to Kent is to work for merging the non-bcachefs stuff first, involving the related maintainers, then do a generic pull request for the "bcachefs code"; the requirement here is that the final pull request has to be self-contained.

Am I too stupid to understand Bcachefs is vaporware and not so good compared to other filesystems such as Btrfs and ZFS or what?

Until bcachefs is merged and more widely tested, nobody can tell how good it is. However to me it seems that is a very complex beast (like btrfs/zfs) and when all the implemented features start to interact each other, the problems bubble up. An example: every one point the finger against the raid5/6 implementation of btrfs; but even the bcachefs one is not ready.
I am not saying that bcachefs is bad; I am saying that when you want cow+raid5/6+quota+snapshot... the mix is very problematic. And until you go in 'mass production', you can't see all the corner cases.

[vladpetric]

Until bcachefs is merged and more widely tested, nobody can tell how good it is. However to me it seems that is a very complex beast (like btrfs/zfs) and when all the implemented features start to interact each other, the problems bubble up. An example: every one point the finger against the raid5/6 implementation of btrfs; but even the bcachefs one is not ready.
I am not saying that bcachefs is bad; I am saying that when you want cow+raid5/6+quota+snapshot... the mix is very problematic. And until you go in 'mass production', you can't see all the corner cases.

Yeap, btrfs needed Facebook to run it internally and fix a large number of one-off bugs ... This is not an endorsement of btrfs in any way, shape or form

[timofonic]

Yeap, btrfs needed Facebook to run it internally and fix a large number of one-off bugs ... This is not an endorsement of btrfs in any way, shape or form

Oh, and Btrfs still has many holes on it. Pun intended!

I hope some company gets interested in Bcachefs.

[vladpetric]

Oh, and Btrfs still has many holes on it. Pun intended!

I hope some company gets interested in Bcachefs.

I think that RAID 5/6 in btrfs is broken by mis-design (bad architecture), more-or-less. If you don't use that, it's probably ok until you have a disk failure and have to manage the array ... sigh.

Yeap, agreed about big corp taking interest in bcachefs ...

[timofonic]

I think that RAID 5/6 in btrfs is broken by mis-design (bad architecture), more-or-less. If you don't use that, it's probably ok until you have a disk failure and have to manage the array ... sigh.

Yeap, agreed about big corp taking interest in bcachefs ...

I wonder how Btrfs got bad architecture. Anyway, offtopic.

I hope Bcachefs doesn't have a bad architecture. Anyone able to understand filesystem stuff can reply about it for us mere mortals?

[vladpetric]

I wonder how Btrfs got bad architecture. Anyway, offtopic.

I hope Bcachefs doesn't have a bad architecture. Anyone able to understand filesystem stuff can reply about it for us mere mortals?

The RAID 5/6 write hole is something that a filesystem needs to a have a solution for ahead of time. I simply don't think BTRFS can introduce a fix to the write hole issue at this time.

A bit circuitous, but the main comments explain the problem:

https://www.reddit.com/r/btrfs/comments/p111o9/raid56_what_is_the_write_hole_failure_mode/

ZFS takes care of the write hole problem through its transactions, pretty much/AFAICT.

https://www.klennet.com/notes/2019-0...%20goes%20away.