Bcachefs Merged Into Linux-Next

[stormcrow]

Classifying filesystems as experimental does not reflect proper categorization; it foregoes nuance in favour of muddying the waters.

No, it's an entirely apt label because it's never been in the Linux mainstream tree before. It's existence outside the tree has limited its adoption and testing. AFAIK, BcacheFS is only used on Linux. Which means it necessarily hasn't had the same widespread testing on other platforms that FUSE & ZFS (many OSes + FSes for FUSE, Linux, FreeBSD, & Solaris and derivatives for ZFS) have outside the tree on several different OSes and environments, or XFS & JFS did before they were ported over from their native systems (Irix & AIX respectively).

It's experimental exactly because it's never been part of the overall upstream build system before. That means its code is going to be exercised in build environments foreign to the ones its builder and relatively small group (compared to the mainstream Linux installed base) of testers and users currently use. It's going to be tested in environments it could have never reached otherwise. That's the definition of "experimental". There will be bugs, perhaps catastrophic data loss bugs, but it's better to find those out in experimental builds and test harnesses before they ever make it to line servers and user's desktops.

[Healer_LFG]

...
What unique feature is offered hat no other provides?
...

Not quite a "unique" feature since you can do it with a few others, or even with LVM, but I'm interested in it's storage pool features. Good ways to use a slow drive and a fast drive in tandem, and have it keep cold data on the slow tier of drives, and hot data on the fast tier of drives.
Note that I'm not talking about caching, where a copy of the hot data is kept on the fast tier *and* slow tier, effectively removing the fast tier of drives' storage capacity from the pool. I'm talking about data persisting on one tier *or* the other, so the total capacity is equal to all the drives in the pool.

There are better enterprise solutions, but once this matures it might be a pretty good candidate for this use-case on consumer desktops running linux.

[blackiwid]

the one thing kent doesn't like to admit is how many times when he was blocked it was the right call.

Again that is pretty irrelevant to me, if he was blocked 99% of times correctly and 1% incorrectly that would still be a wrong doing and I doubt it was in 15 years not 1 good commit he tried to make. Even that he says "he tried to block everything" either that is paranoia or if it's true somebody else did in fact decide that Kent was right and this person is wrong, and that would proof unfair treatment and I doubt, it's 15 years because of incompetence that is not high enough to get him kicked from the position, it seems to be a vendetta.

And Yes I grant some level of speculation but I just try to go through a logical analysis and assumptions that seem most likely to me. And I said it should be determinable or somebody should know who he means and if the claim has any or full truth in it, and if they are completely baseless I think somebody would pointed that out and would probably based on that some sort of defamation for now make inclusion impossible I would not want to have a person that tries to cancel somebody baseless anywhere near my project.

But maybe that is only me, if somebody accused somebody as rapist as example I would want either the lie or the act be proven if it's possible to find out the truth and do actions depending on that analysis I would not say "who knows let's let it at a he said she said point" and pretend nothing did happen.

I just have a feeling that many people know which person he accuses of that, so I would buy ignoring that if the person would be really unknown a claim of a moral really bad thing, without a name doesn't necessarily need a truth finding process, but I doubt that the person is really unknown to many of this community.

[evert_mouw]

For Btrfs is coming, there are some patches in review: https://lore.kernel.org/linux-btrfs/[email protected]/

It's nice to see fscrypt support emerging for btrfs. Still, btrfs doesn't have exactly a good reputation and bcachefs has the encryption stable already. But sure when btrfs has stable fscrypt support I will consider to use it. Fscrypt is nice and I already use it sometimes with ext4.

[oiaohm]

Again that is pretty irrelevant to me, if he was blocked 99% of times correctly and 1% incorrectly that would still be a wrong doing and I doubt it was in 15 years not 1 good commit he tried to make.

First Kent was not blocked for 15 years his bcache patches have been going in. But when they are submit to Linux-Next Kent as regularly need to redo them. Yes this is for issues that if he was following the patch checklist he should not be doing. Lets just say the maintainer of Linux-next is not exactly happy with Kent but he is professional enough that even that he knows kent is going to cause him extra workload he still accepts the patches and works on getting them up to quality..

I will not be surprised if at the next linux merge window if bcachefs patches get removed from Linux-next to be resubmitted after new kernel branch for the new release has branched off into Linus branch.

The assumptions you are using have been way off from reality of Linux kernel development. Yes you assumes style errors are not critical errors when in reality for the way Linux kernel development works they are critical errors. Yes part of your submitting patches checklist

https://www.kernel.org/doc/html/latest/process/submit-checklist.html

Check your patch for general style as detailed in Documentation/process/coding-style.rst. Check for trivial violations with the patch style checker prior to submission (scripts/checkpatch.pl). You should be able to justify all violations that remain in your patch.

There a lint for style you are meant to run as point 5.

Check cleanly with sparse.

Point 9 tool to find coding defects.

Point 2 your code has to build without error is just the starting point.

The reality here is the code Kent has been submitting does not pass the Linux Kernel patch submission checklist.

Be-aware item that a maintainer spots that should have been detected by what the person submitting the patch should have already done the Linux maintainer general orders other linux-next is to reject patch.

Going around the maintainers to Linus does not change the code quality requirements for submitting a patch to the Linux kernel. Kent basically went to the boss without the minimal i dotted and t crossed.

But maybe that is only me, if somebody accused somebody as rapist as example I would want either the lie or the act be proven if it's possible to find out the truth and do actions depending on that analysis I would not say "who knows let's let it at a he said she said point" and pretend nothing did happen.

That not what happened. Kent patches would be reject for X valid reason. Then he would submit them again get Y valid reason. Each time one of these reasons was something that if he was doing the Linux Kernel patch submission checklist the automatic tools would have told him was the problem.

Maintainers like document editors they are allowed to minor corrections to patches but that it anything more they have to reject the patch that is their job.

Yes the VFS maintainer did ask Kent if he was doing the checklist even gave link to it and Kent blind face lied that he was and also was using threats that he would go over his head to Linus. So the VFS maintainer let him go to Linus and stopped working on his patches. That in the VFS maintainers mailing list.

I do know that doing the Linux kernel submission checklist can tie a 8 core computer up for 2 days and that if you don't have to fix anything. Remember every time you need to fix something to pass the checklist it equals running the complete thing again. There is a lot of work getting code up to quality the Linux kernel needs.

Yes submitting to Linux-next where the checklist is going to auto-run also means Kent is going to have to fix things.

Kent has been like a game cheater wondering why in hell they are getting banned and still wanting to use cheats. There is no question that Kent is guilty of doing the wrong things not one of his rejections was in invalid grounds.

Getting up to the quality the Linux kernel need can be a very frustrating process. Like having a tab where you should have spaces will be a error so your code is rejected because style is wrong so checkpatch.pl will not accept it. Of course this would be less frustrating if person understand that that tab/space error could cause a semantic patch to apply incorrectly in future and that why it has to be fixed now.

This is the thing the Linux kernel patch checklist looks to find a stack of minor not critical errors but with the time Linux kernel developers have be doing this they wrote the checklist to prevent people from inserting minor errors that have historic documented cases of causing major errors as they interact with future patches.

blackiwid I would not dispute that tools that do the code quality check could not be more descriptive of why these errors must be fixed with like historic examples of if this is left in your code we risk this historic major error. The process would still reject the same poor quality patches but some people would not get as frustrated so reducing their temptation to cheat the system. But this also required technical writers that the Linux kernel development is highly lacking in.

[NobodyXu]

blackiwid You are just as clueless as ever on what code review is and how it works.

You've been idolising Kent the entire time and turning this into politics, funny that you are pointing fingers to developers/maintainers actually doing their job reviewing patch from Kent and points out things that have to be/can be improved.

[brucethemoose]

I see quite some enthusiasm here for BcacheFS, but I wonder what people expect to gain.
Why is another experimental filesystem so desirable? What performance jump do you expect to see?
What unique feature is offered hat no other provides?

With respect to filesystems I am in the conservative camp.

I am hoping for some bells and whistles of btrfs/zfs without their finickiness, and with filesystem overhead more like ext4/xfs/f2fs.

Tiered storage seems really cool if it ends up being stable.

[shmerl]

Good to see the drama calming down and things moving in the right direction.

[Sonadow]

blackiwid You are just as clueless as ever on what code review is and how it works.

You've been idolising Kent the entire time and turning this into politics, funny that you are pointing fingers to developers/maintainers actually doing their job reviewing patch from Kent and points out things that have to be/can be improved.

Clueless? Turning this political?

Remind me again which kernel has maintainers who are given full power to block patches and contributions from a Russian developer and the Russian company he works for just because it's Russian?

[Berniyh]

This isn't the first time I've read this, what problems did Valve have with btrfs? What makes you think it will change filesystem? They actually recently contributed to Btrfs for a feature they need on the Steam Deck: https://lore.kernel.org/linux-btrfs/[email protected]/

One downside of btrfs for that particular use case is that it does not yet support casefold, i.e. case-ignoring file lookup, like Ext4 does.
Don't know if bcachefs does support it.
Nevertheless, I don't see Valve using a new, pretty much untested filesystem in an end user product.

btrfs had problems in the beginning, but it has matured and can be considered stable (apart from the whole raid5/6 madness).