Bcachefs Publishes Patches For Disk Accounting Rewrite

[phoronix]

Phoronix: Bcachefs Publishes Patches For Disk Accounting Rewrite

Kent Overstreet on Saturday evening posted a set of 21 patches to overhaul the disk accounting code for the Bcachefs file-system. This change does break compatibility with the existing disk accounting on-disk format and thus will require an upgrade when moving to the new version, which may land for Linux v6.9...

https://www.phoronix.com/news/Bcachefs-Disk-Account-Rewrite

[timofonic]

They don't worry to change formatting and provide migration ways, that's good in my opinion. I wish other filesystems would do the same too.

[varikonniemi]

They don't worry to change formatting and provide migration ways, that's good in my opinion. I wish other filesystems would do the same too.

I think that's largely a question of what has to be changed and how it interacts with the rest of the codebase and what's on disk. When you see on disk format changes that need to re-create the filesystem it's because there is such fundamental change that upgrade does not make sense, for example if it entails unmounting/locking the FS and rewriting all the data. As it is pretty much equivalent to backup-reformat-restore.

Here just a new btree is created, and the code changed to use it instead of whatever the current accounting was doing (writing it as metadata in journal?)

[fitzie]

been a while since we recap'd kent's attitude.

1) dan carpenter (smatch developer)

https://lore.kernel.org/linux-bcache...3frunhduf3so66 @tjhcdoq6unk3/

after the last episode the hate continues with kent saying "entirely too much of the traffic on this list is
getting taken up by static analyzer bullshit"

Kent pushes for it to be made into a dashboard, and when that isnt' agreed to he says "naw that's just making excuses " https://lore.kernel.org/linux-bcache...54tersrt6j5ywx @zjic2wbvralq/

And when Dan finally had enough of the abuse, the thread ended up like this

https://lore.kernel.org/linux-bcache...3gcrea2ekpepdo @qdqou5453ykb/

On Thu, Feb 22, 2024 at 08:24:58AM +0300, Dan Carpenter wrote:
> To be honest, the point of explaining how to run Smatch was really to
> let you know that you're now on your own.

Ok that's fine - in that case, I just need to ask you to stop bugging me
to get me to explain smatch bugs to you.

[fitzie]

2) linux mm developers

this is a neat capability that would help trace how the kernel is using memory with a lot more detail, and the patch submitter Soren seems to have worked closely with Kent. However, Kent makes his presence known to everyone not immediately blessing this patch.

https://lore.kernel.org/linux-fsdeve...e6siaewizoooyw @pdd3tcji5yld/

You gotta stop with this this derailing garbage.

there's not much feedback from mm developers, and even those that have negative feedback say they would be okay with this if other mm developers would approve.
here there's a little thread where solutions are proposed to get more buying from mm, by this developer David, either from an upcoming conference or a meeting instead of the mailing list, which wasn't generating the response kent wanted.
https://lore.kernel.org/linux-fsdeve...7x2x4ecz277k4o @gjfy2lu7ntos/

A meeting wouldn't be out of the question, _if_ there is an agenda, but:

What's that coffeee mug say? I just survived another meeting that
could've been an email? What exactly is the outcome we're looking for?

David later stuck up for the process: "
This won't get merged without acks from MM people.
"

and it finally goes off the deep end when kent promised to go to linus and skip the mm maintaners.
https://lore.kernel.org/linux-fsdeve...tgjbo37tlisexa @caq633gciggt/

> I certainly cannot be motivated at this point to review and ack this,
> unfortunately too much negative energy around here.

David, this kind of reaction is exactly why I was telling Andrew I was
going to submit this as a direct pull request to Linus.

This is an important feature; if we can't stay focused ot the technical
and get it done that's what I'll do.

later, the patch submitter, soren, stated that:

Well, I'm definitely not trying to bypass the MM community, that's why
this patchset is posted. Not sure why people can't voice their opinion
on the benefit/cost balance of the patchset over the email... But if a
meeting would be more productive I'm happy to set it up."

there's already been a follow up patch submitted and kent has stayed out of the conversation, so its been more productive without any blowups. we'll what happens if and when this is submitted for merging. it does look like it will be a very cool bit of tech.

[fitzie]

3) greg k.h linux-stable.

this started with a bang, where kent (who doesn't follow any of the rules blows up at the stable team):

https://lore.kernel.org/stable/dlxqu...q4ivi7notzs6jf @itt42d42zmsw/

What the f*ck?

(redaction by me).

This was targeted at sasha who responsds: "Is this really how you communicate with other humans?"

The back story is that kent wants to manage the stable tree of bcachefs himself, which is a good idea, since the way stable picks up patches automatically (using a script called autosel) has not always picked up the proper patches. So the stable guys put in a blacklist entry to the stable autosel script would ignore bcachefs patches. but that script picked up some bcachefs patches anyway due to kent's abuse of well establed commit tags ("Fixes:"). But that's not good enough for kent. He defends his abuse of the commit tag, demands the stable team come up for a solution for his workflow, and also entirely change their workflow to what kent thinks it should be.

To the question of why the stable tree has the workflow it does, Greg posts a funny response. Here https://lore.kernel.org/stable/20240...r-fb3f@gregkh/

Hi,

This is the friendly email-bot of the stable kernel team. I've detected that
you are asking a question that has been discussed many times in the past. If
you wish to contact the stable developers directly, please use their phone
hotline, 1-800-382-5633.

thanks,

stable email bot

----------------

*beep beep beep beep beep beep beep beep beep beep beep*

*ring* *ring*

This is the Linux stable kernel team's phone line.

Please listen to the following menu fully as the items have changed
recently.

To contact the Linux stable developer's directly, please press 1.

To contact the Linux stable develop—
*1*

I've truncated the full response from Greg, which while being funny does fully explain why stable works the way it works. I won't go throughout the rest of the thread but rest assured kent is being an ass. He thinks it's somehow stable teams problem for coming up with a solution for his problem tracking patches, when the stable team notes, that Kent isn't allowed to violate the rules for cc'ing stable or the Fixes tag it git comments.

[varikonniemi]

Thanks for doing a deep dive on current kernel politics, i was only aware of the happenings on bcachefs mailing list i follow.

In the thread you linked the last messages seem to be that everyone is on the same page and understand each other after a IRC conversation, so it really just seems like people of different generations and communications styles being unable to communicate effectively in non-interactive format.

[nadir]

Thanks for doing a deep dive on current kernel politics, i was only aware of the happenings on bcachefs mailing list i follow.

In the thread you linked the last messages seem to be that everyone is on the same page and understand each other after a IRC conversation, so it really just seems like people of different generations and communications styles being unable to communicate effectively in non-interactive format.

Not I think any of the involved would want that, but I sometimes think a video call now and then might help give the empathically challenged among the developers a chance to see the humanity of others.

[varikonniemi]

Not I think any of the involved would want that, but I sometimes think a video call now and then might help give the empathically challenged among the developers a chance to see the humanity of others.

bcachefs has a video meeting once per week. But it's not something higher level people like GKH seem to have time or interest to attend.

[fitzie]

Thanks for doing a deep dive on current kernel politics, i was only aware of the happenings on bcachefs mailing list i follow.

In the thread you linked the last messages seem to be that everyone is on the same page and understand each other after a IRC conversation, so it really just seems like people of different generations and communications styles being unable to communicate effectively in non-interactive format.

the stable issue? Greg is a professional, and didn't take the bait of kent's many digs. He understands that kent wants to submit a branch (as opposed to patches), and is willing to do that as long as that branch is made up properly. I didn't see any reference to IRC, but I may have missed it.

I was only turned on to this issue because I saw kent reference the "stable fiasco" in his disk accounting rewrite announcement. So I don't think the issues are smoothed over. On this particular issue Kent isn't wrong to say that there needs to be a more web based workflow for kernel development. Even Linus has said as much, but kent just locking horns with everyone doesn't make the future happen any quicker.

Sadly I consider his attitude to be a real risk to the adoption of bcachefs. I was a fan and patreon support of bcachefs for many years, and while I'm still hopeful that it will deliver a great capability for linux, I do think it's going to be many years before hyperscalers and distros are willing to engage with it and that's got a lot to do with kent's "style".