Bcachefs Fixes Pull Once Again Frustrates Linus Torvalds - Two Choices Offered

[PuckPoltergeist]

The tl;dr is that...

Hail to the Kent!

[oleid]

Birdy being a voice of reason?
I never thought I'd see the day!

And Birdy was right, they figured it out after getting some sleep:

https://lore.kernel.org/linux-fsdevel/172816780614.3194359.10913571563159868953.pr-tracker-bot@kernel.org/T/#mca69a8f3d2d52604459a7b35b4b13740c3f1cbfb

[fitzie]

Aside from a couple of patches that kent posted which were actually older than the RC, its just that Kent did final cosmetic changes (something that Kent agreed he would stop doing mind you), the other isses weren't even Kent's fault.

When Linus ranted about the build being broken, that wasn't Kent's fault, that was Christians. He pushed code that broke the build in 6.12-rc1 by doing VFS changes and not doing the neccessary updates to btrfs, thats not Kent's fault.

And with the big endien'ess issue, again the problem here is that no one is running a fuking 3 decade old architecture machine to build the Linux kernel as their development box.

The core issue here isn't Ken, its that the development model of Linux is so fuken anitquated that unlike almost any other modern OS projtect that I can think of, they don't have a CI that does regular builds, to you know check for these things. Something that Kent ironically is having to build because he is sick of being scapegoated/blamed for issues that he didn't even cause.

And if Linus thinks that machines with big endieness are so important to rant about it, maybe the CI should be running some ancient motorola to check for such build failures rather than relying on that one ancient enterprise with a 30 year old IBM-Z mainframe to figure out that the linux kernel aint building.

this is kent logic. turning a human problem into a debate on technology or process. this isn't to say that the kernel process is perfect, but it's a finely tuned machine, as linus recently said, they have had a string of releases all at the 9 week mark. which is pretty good. at the end of the day, it's really linus's process, and linus _wrote_ git to make his workflow better, and I don't think linus is holding on to antiquated stuff, although I admit is is very custom for his way of doing things. honestly, if you dig into the CI thing it's about a dashboard, and perhaps forcing bots to do certain CI tests, because there are plenty of bots building what's in linux next. but just sending emails and doing whatever tests they deem fit and not what kent wants. Anyway, now kent and linus have come to some sort of agreement. we'll see if it does the trick.

https://lore.kernel.org/linux-bcachefs/172816780614.3194359.10913571563159868953.pr-tracker-bot@kernel.org/T/#m4d01e4eb710181e5e21646ac97b158a38a1771a2

[mdedetrich]

this is kent logic. turning a human problem into a debate on technology or process. this isn't to say that the kernel process is perfect, but it's a finely tuned machine, as linus recently said, they have had a string of releases all at the 9 week mark. which is pretty good. at the end of the day, it's really linus's process, and linus _wrote_ git to make his workflow better, and I don't think linus is holding on to antiquated stuff, although I admit is is very custom for his way of doing things. honestly, if you dig into the CI thing it's about a dashboard, and perhaps forcing bots to do certain CI tests, because there are plenty of bots building what's in linux next. but just sending emails and doing whatever tests they deem fit and not what kent wants. Anyway, now kent and linus have come to some sort of agreement. we'll see if it does the trick.

https://lore.kernel.org/linux-bcache...b158a38a1771a2

No Kent is absolutely right, the Linux process is like a Kafka'esque bueracracy, which only works when you have old timers that know some specific rules (which are in fact guidelines) to keep things running but don't make sense to anyone new coming in.

The point Kent made is quite alarming, the pool of fs contributors has declined to the point where its only really aging greybeards, and Kent's own iniative of building his own CI system has actually brought in new developers since they can now productively see if their changes are breaking anything and at the same time releases a lot of burden off of Kent.

Give Kent some credit here, what is really going on is that Kent is putting a massive torchlight and the frankly primitive release process that Linux has which make no real sense outside of Linux. Like you have to be a special kind of braindead to argue against a simple CI that at least does some basic builds for the current in progress fs subsystem branch and runs some basic tests.

And again as birdie pointed out, they solved this as adults and yet again people are just making a big drama to make newsworthy headlines without any real history/experience (these kind of debates happen all of the time on lkml, its just bcachefs that is getting the attention because people have high hopes for it).

[waxhead]

Thats debian's fault due to how it mandates packages be built, other distro's don't have these issues at all.

So when was right and wrong based on what the majority choose to believe? In fact history have shown over and over again that the majority is often wrong, and sometimes the minority change the belief system of many with their ideas.

[mdedetrich]

So when was right and wrong based on what the majority choose to believe? In fact history have shown over and over again that the majority is often wrong, and sometimes the minority change the belief system of many with their ideas.

No its actually debian who was at fault here, literal quote from https://lore.kernel.org/lkml/v2k6atl...@3k4knhrlnqeb/

My issue wasn't with Debian as a whole; it was with one particular packaging rule which was causing issues, and a maintainer who - despite warnings that it would cause issues - broke the build and sat on it, leaving a broken version up, which resulted in users unable to access their filesystems when they couldn't mount in degraded mode.

This is literally debians fault, that has a packaging rule unique to the distro which create a broken btrfs-utils. Kent even warned the maintainer that this would happen, and Kent was ignored.

Stop going into conspiracy level thinking, its not hard to figure out what is the actual case through some critical thinking and reading.

[fitzie]

No Kent is absolutely right, the Linux process is like a Kafka'esque bueracracy, which only works when you have old timers that know some specific rules (which are in fact guidelines) to keep things running but don't make sense to anyone new coming in.

The point Kent made is quite alarming, the pool of fs contributors has declined to the point where its only really aging greybears, and Kent's own iniative of building his own CI system has actually brought in new developers since they can now productively see if their changes are breaking anything and at the same time releases a lot of burden off of Kent.

Give Kent some credit here, what is really going on is that Kent is putting a massive torchlight and the frankly primitive release process that Linux has which make no real sense outside of Linux. Like you have to be a special kind of braindead to argue against a simple CI that at least does some basic builds for the fs subsystem and runs some basic tests.

And again as birdie pointed out, they solved this as adults and yet again people are just making a big drama to make newsworthy headlines without any real history/experience (these kind of debates happen all of the time on lkml, its just bcachefs that is getting the attention because people have high hopes for it).

you keep stating that linux doesn't have any CI, but there's plenty of CI. in fact there was a recent video from plumbers conference that the kernelCI linux foundation team held, where they talked about putting the fs-next CI into some sort of dashboard.

https://youtu.be/DLOsldz9E-g

this isn't arguing against CI, it's arguing that kent is acting like a child, and all his technical/process reasons are flawed. everything kent has asked for was already documented very clearly, outside of of the initial inclusion into upstream, which obviously is cannot be standardized because it's always a custom thing.

I do agree that kent brings up an interesting issue with graybeard, but that's certainly a long term thing, and i don't think there's a silver bullet like setting up a CI will bring a bunch of new programmers to the table. this is a long term issue and doesn't justify kent not posting patches to mailing list.

[mdedetrich]

you keep stating that linux doesn't have any CI, but there's plenty of CI. in fact there was a recent video from plumbers conference that the kernelCI linux foundation team held, where they talked about putting the fs-next CI into some sort of dashboard.

Do you have some reading deficiency, Kent is the primary person getting the CI to work on fs-next and the reason why he is doing that is because it would literally solve all of the issues that Linus complained about wrt to broken builds and thats is what Kent told him.

Thats what was literally laid out in the post.

I dunno man, I am getting the impression from your posts that you have some kind of massive hard on for defending doing things in the stupidest way possible "because it was always done that way" and if someone argues against that you crucify the person for daring to question it. A lot of the problems can easily be solved with tools, and thats a much smarter way to solve that problem mrather than burning people out by treating them as tools which is exactly what Kent was said was happening to him (as he stated he already has enough on his plate).

Stop putting both Linus and the current Linux processes (which we just found out are more like guidelines than actual rules, Linus's own lilteral words) on a pedestal. If nothing else, Linux needed someone like Kent to show how silly they do stuff there.

I do agree that kent brings up an interesting issue with graybeard, but that's certainly a long term thing, and i don't think there's a silver bullet like setting up a CI will bring a bunch of new programmers to the table. this is a long term issue and doesn't justify kent not posting patches to mailing list.

Its not a silver bullet but its a massive factor. I personally for one thing wouldn't even consider spending time developing on Linux kernel if there isn't some basic CI because its not worth my time especially considering that almost every single other OS project has a CI.

A person just posted on that same lkml stating exactly that https://lore.kernel.org/lkml/[email protected]/

[dfyt]

btrfs is broken when it comes to RAID 5/6, which is something that it even now warns you when you try to create the filesystem (they only added the warning a couple of years ago).

What people like Alexmitter conveniently leave out is that those wonderful btrfs datacentres have UPS rooms the size of houses with diesel generators running 24/7 despite mains power. I know cause I ran a company maintaining and installing those generators. Personally both bcachefs (2 months ago) and btrfs (10 months ago) have lost data for me and thats on a simple 1 disk setup both required a format of the fs to get it working again, scrubs and "repairs" did bugger all. ZFS is the only fs I trust for now but btrfs is growing on me - I just prefer zfs' snapshots unless someone can show me a reliable way to make nested snapshots with btrfs. ZFS is the only FS I haven't lost any data on ever.

[mdedetrich]

What people like Alexmitter conveniently leave out is that those wonderful btrfs datacentres have UPS rooms the size of houses with diesel generators running 24/7 despite mains power. I know cause I ran a company maintaining and installing those generators. Personally both bcachefs (2 months ago) and btrfs (10 months ago) have lost data for me and thats on a simple 1 disk setup both required a format of the fs to get it working again, scrubs and "repairs" did bugger all. ZFS is the only fs I trust for now but btrfs is growing on me - I just prefer zfs' snapshots unless someone can show me a reliable way to make nested snapshots with btrfs. ZFS is the only FS I haven't lost any data on ever.

I mean I wouldn't take a single word of what people like Alexmitter or Volta take seriously, if we werent dealing with the Linux kernel you would think that they were getting paid to spread shit about everything else.

I am however interested to hear how you managed to lose data with bcachefs (although its very new to the tree so its not that shocking). btrfs is not that surprising, and well ZFS is what people know ZFS to be, somethng that is basically alien level tech when it comes to not losing data and still happens to maintain that.