Bcachefs Publishes Patches For Disk Accounting Rewrite

[lyamc]

By the way, the upgrade/migration from my past experience has been transparent. If it tries to mount and it needed to be migrated/updated to new version, it would do that, and then mount it.

[PuckPoltergeist]

Am I the only one getting memories of Hans' discussions from Kent's?

No, I've already mentioned this too

[yump]

It wouldn't be a bcachefs thread with fitzie prosecuting his labor-intensive vendetta against Kent Overstreet...

Imagine if you had a guy who read all your work-related email and wrote up weekly commentaries that cast aspersions on your character, like some kind of Truman Show episode recap.

[PuckPoltergeist]

It wouldn't be a bcachefs thread with fitzie prosecuting his labor-intensive vendetta against Kent Overstreet...

Why do you think it's a vendetta?

[Mitch]

first, the script to skip bcachefs broke, triggered by kent abusing commit tags. He literally committed "Fixes:" (with nothing after the colon). so it ended up pulling it in the patch. but that had nothing to do with why the stable submission failed. and when kent was told why his patches weren't included in the stable rc, he blamed them for not telling him, but they did tell him (all documented in a separate email thread).

But the bigger issue was that kent didnt' generate the stable patches correctly, which involves tying the patches to specific commits in linus's kernel git. That is a policy rule of stable, which says that what is in stable has already been included in linus tree (doesn't have to be identical, but it has to be directly related).

This annoyed kent in several ways. First was the fact that kent didn't know about "git cherry-pick -x" flag was a documentation issue. Second, kent thinks he as bcachefs maintainer should be able to send whatever he thinks is appropiate, and that's supersedes tying it to linus's repo. Third, kent disagreed with sending things as patches, and thinks stable it should be some dashboard git branch merge tool.

Kent' always getting emotional over technical disagreements is his biggest fault, but his habit on lashing out when he made a bad assumption or was ignorant of some process or technical detail is another big issue of his. the number of times people have explained something to him he didn't know will pretty much guarantee he will start ranting about documentation.

Yeah, I love Kent's work, and he's a thoughtful and intelligent person. But he tends to drive people crazy he works with. It probably sucks to be on the receiving end. I work with a few difficult people, and it's frankly really annoying how their mood and temperment is a roll of the die in every interaction.

[PuckPoltergeist]

By the way, the upgrade/migration from my past experience has been transparent. If it tries to mount and it needed to be migrated/updated to new version, it would do that, and then mount it.

That's standard, other filesystems have done this many times before. Nearly all times this is a one way, flagging the filesystem when the upgrade is done. This means, the filesystem can't be mounted with an older kernel that don't know the feature. And often it can't be handled by older tools. The interesting part here is, as far as I've understood this right, the possibility to revert this change. Mounting a migrated filesystem with an older kernel will revert the change. I'm not sure how this might work, as older kernels don't know bout the migration path. I'm curious how this will work.

[Quackdoc]

always glad to see new bcachefs stuff being posted, but Im a bit puzzled by this

The old disk accounting scheme was fast, but had some limitations:

I hope this doesn't mean the newer implementation is slow.

[varikonniemi]

That's standard, other filesystems have done this many times before. Nearly all times this is a one way, flagging the filesystem when the upgrade is done. This means, the filesystem can't be mounted with an older kernel that don't know the feature. And often it can't be handled by older tools. The interesting part here is, as far as I've understood this right, the possibility to revert this change. Mounting a migrated filesystem with an older kernel will revert the change. I'm not sure how this might work, as older kernels don't know bout the migration path. I'm curious how this will work.

fsck sees the filesystem is "broken" and fixes it to the older format. Also some preparatory work has already gone in so that it's reliable when doing this kind of "fix".

[Jessica]

It is pretty obvious that Kent is neurodivergent / a little autistic. As a neurodivergent person myself, I don't really see a problem with his responses, but I understand not a lot of people appreciate bluntness or directness in that manner.

[PuckPoltergeist]

fsck sees the filesystem is "broken" and fixes it to the older format. Also some preparatory work has already gone in so that it's reliable when doing this kind of "fix".

Sounds reasonable, but is a way back to the "old" user-space fsck instead of self healing filesystem. And this approach is assuming an actual fsck. So just putting a disk with new format into an old server won't work. Let's see how helpful this will be in real life.