Bcachefs Looks Like It Won't Make It For Linux 6.6

[mdedetrich]

CoW brings the same benefits for desktops as for servers or enterprise systems. In fact the only two workloads that are notoriously CoW-averse are databases and virtualisation, those are not typical desktop uses Anyhow, the majority of the world's enterprise systems run Windows.

I'm not talking about Desktop enterprise such as Windows, I am talking about companies such as Oracle or Meta, that stores vast quantities of data which is where CoW really shines (easy snapshotting, data integrity etc etc).

The benefits for desktop are benign in comparison, I mean Windows desktop OS is "surviving" (if you want to call it that) on ntfs.

[timofonic]

I think there's some hope.

I think the linux-next procedure and such must be better documented.

https://www.kernel.org/doc/man-pages/linux-next.html

but chandan was asking a couple of weeks ago what the exact process was for merging branches and importing patches

Right now, documentation of certain procedures is CRAP

[oiaohm]

You mean the VFS maintainer that had an issue with something, so kent asked about it and got ghosted? yeah I would try and ignore him too then.

VFS maintainer had told him to put the code in next branch 4 times before ghosting him.

they didn't, he did actually get reviews from some people, just not the people in question.

Read the patch submission checklist. Zero compiler errors. Of course you are going to be ghosted. Lot of the maintaienrs have auto patch checkers this means you patch auto deletes from their list to review as soon as it throws a compiler error because it has to be a defective patch that must have been damaged somewhere right.

[oiaohm]

I think there's some hope.

I think the linux-next procedure and such must be better documented.

https://www.kernel.org/doc/man-pages/linux-next.html

Right now, documentation of certain procedures is CRAP

I do agree the documentation around linux-next does need to be made clearer what it is and how much automation is there. But when the head maintainer in the area is tell you to put your code in linux-next branch following directions should be done.

The thing here is the standard patch checklist says you patches submitted should not have a single compiler/linker error. Kent Overstreets bcachefs patches have had compiler error after compiler error that are compiler errors for bad code.

Not obeying the patch submission checklist/rules unfortunately is way to get ghosted. Linux maintainers are very overworked and some have automated systems on there inbox that will automatically drop patches from their reviews that don't pass the min quality standard of no compiler/linker errors. The bots on linux-next will bother writing over these issues where humans will not. Like it or not Linux Kernel maintainers have enough work load human processing patches that pass the min standards dropping patches that don't pass min standards is part of the way their workflow is optimized..

Submitting poor quality code like it or not does not end up with Linux development system working normally. Deciding to disobey the maintainer in control of a particular sections direction is also another way to have the system not function normally.

Please note Linux maintainers should know the patch checklist and be using it for their own stuff. The question is why in hell was Kent Overstreet think not doing these things would not cause problems.

Like it or not Kent Overstreet brought his problem on his self. Yes maybe the system need to be made better.

[andresdju]

It is well known in German culture. But what he is describing is not really catching it. kafkaesque is much stronger. Even if you have the best social abilities you are helpless but what we here see is the typical programmer level of social abilities. ;-)

Also a very common word in Spanish. I agree that this situation isn't kafkaesque at all. The little interaction I had with Kent was very nice, but it's clear that he doesn't know how to manage disagreements in a healthy manner (specially healthy for him).

I think that he is also a bit careless, when I asked him years ago about some issues building bcachefs on arm he replied that bcachefs wasn't much tested on arm. Bcachefs should be merged in linux-next, with the amount of implementation dependent behavior of C (specially depending on the arch), bcachefs could have issues on some of the upstream supported architectures.

[blackiwid]

You are wrong that cartoon has been done in English as the particular episode you referenced can buy it as part of "The Twelve Tasks of Asterix" also released in dub english as movie ~ 41 min in your will also find that item in the "The Twelve Tasks of Asterix".

No I am not wrong "clipped" means that you seperate this part and put it on a video plattform in this case Youtube, you don't find the clip on youtube or at least I couldn't, not even in longer form, but you would expect this specific part of this 12 seperated because it's such a cult clip. It's there in german and french but not in english.

Remember Axterix wins that clip by understanding the bureaucracies rules and use them to his advantage.

Software development when you want quality code like or not is nice process. Its really simple to get personal goals and ego and get upset.

That is a completely misrepresentation of what happens, he A lies and B destroys them by making them all crazy, and weaponize their process against them to make the system collapse. So he doesn't play their game (after he understands it) he also don't follows the process to succeeds but he cheats / lies to destroy the system and then get the goal by NOT follow the rules.

[blackiwid]

The reality here is if Kent Oversteet had obeyed instructions back in June/July the bcachefs code would most likely being merged right now. But hey he was smart than the average bear and decide to go over Christian Brauner head and go straight to Linus Torvalds. Once the code is merged into linux-next branch expect to see Christian Brauner comment.

That doesn't explain the communication from Linus, why does he say he should add this pgp keys and make it compile when he clearly could say "without linux-next you will not be added this round POINT!" I rather have negative feedback that is on point and honest than some vague mixed messages.

Why doesn't he say "hey Christian told you" so.... why does he say "it's my fault not noticing it" does he try to sugarbread him to keep going because he wants the cake and eat it, too? Be strong but somehow be nice to him (lie) to keep him going because he wants the code?

Is that some new policies to talk like you would talk to asiats to not insult him or something, you can say the unfiltered truth without being rude. I dislike this unclear communication, something is smells wrong and I don't see the full blame on Kent, if that would be the case, be clear about it...

[NotMine999]

It's not fair when these rules are not codified, or are seemingly created on the whim, and finding them means crawling and analysing the most inaccessible format (a mailing list).

imo the whole mailing list thing severely raises the bar on how accessible Linux is to new developers who wish to contribute. In a few decades when current maintainers and developers have retired or passed, I predict they'll be a significant shortage of people that can do development of the kernel.

So you expect programmers to write documentation?



You must not know programmers very well.


Actually LK development has been documented. Well, it's been documented to death in what I think are incredibly overblown and voluminous ways. Reminds me of a BIG CORP, now TWO BIG CORP that I used to work for.

Procedures here. Rules there. Procedures and rules everywhere.

An environment that was DEFINITELY not designed for fast & flexible development, nor was it responsive to customer demands. It had all the internal inertia of frozen ice; Heinz Ketchup flows faster than the internal inertia that I encountered.

And that also describes Linux Kernel Development perfectly.

[MorrisS.]

1) Paging out (into swap)
2) Paging in (from swap)

so what is the solution and how to apply it? (also previous kernels appear to be affected)

[timofonic]

Another interesting reply...

On Wed, Sep 06, 2023 at 05:03:06PM -0700, Kees Cook wrote:
> On Wed, Sep 06, 2023 at 03:28:47PM -0700, Nathan Chancellor wrote:
> > Hi Kent,
> >
> > On Sat, Sep 02, 2023 at 11:25:55PM -0400, Kent Overstreet wrote:
> > > here's the bcachefs pull request, for 6.6. Hopefully everything
> > > outstanding from the previous PR thread has been resolved; the block
> > > layer prereqs are in now via Jens's tree and the dcache helper has a
> > > reviewed-by from Christain.
> >
> > I pulled this into mainline locally and did an LLVM build, which found
> > an immediate issue. It appears the bcachefs codes uses zero length
>
> It looks like this series hasn't been in -next at all? That seems like a
> pretty important step.
>
> Also, when I look at the PR, it seems to be a branch history going
> back _years_. For this kind of a feature, I'd expect a short series of
> "here's the code" in incremental additions (e.g. look at the x86 shstk
> series), not the development history from it being out of tree -- this
> could easily lead to ugly bisection problems, etc.

I disagree entirely.

One of the most valuable things we have for XFS is a complete change history going back to the first commit in 1993. We don't have all that in the kernel git tree - that only goes back to 2005. We do, however, have a separate git archive that runs from the initial commit in 1993 to 2008, and so we can track bugs and changes back all the way to when they were first introduced.

I'm looking at something in that historic XFS archive every second day; understanding the XFS code and why it is like it is requires
looking back in time on a regular basis. And because XFS engineers have been really good with commit messages for a really long time, there is a lot of information in that historic archive that is simply not documented anywhere else.

So if we have the full history of bcachefs developement sitting in a git tree, we'd be *utterly stupid* to discard it when merging it into the mainline tree. Nothing else documents the reasons for the code being like it is right now better than the change history of the code. For people trying to understand the code or trying to perform root cause analysis of a bug, a complete revision history is a rich gold mine full of valuable nuggets....

-Dave.
--