koverstreet

His job is to create drama, and argue over things that don't need to be argued?

Linus has never once found a mistake in the bcachefs pull requests, but he has created massive headaches for getting bugfixes out to users that were waiting on them.

> In the comments on HN around any bcachefs news (including this one) there are always a couple throwaway accounts bleating the same arguments - sounding like the victim - that Kent frequently uses.

And every time something like this comes up, I end up with every sort of accusation pointed at me, and no one seems to be willing to look at the wider picture - why is the kernel community still unable to figure out a plan to get a trustworthy modern filesystem?

> This is your problem to fix.

No, I've said from the start that this needs to be a community effort. A filesystem is too big for one person.

Be realistic :) If the community wants this to happen, the community will have to step up.

Just looking for somewhere to stick that pitchfork, eh?

Eh? Linus has called it "experimental garbage that no one could be using" a whole bunch of times, based on absolutely nothing as far as I can tell.

Meanwhile just scan the thread for btrfs reports...

I need to write up a proper patreon post on all this stuff, because there's a lot of misinformation going around.

No, I was not "ignoring the merge window". Linus was trying to make and dictate calls on what is and is not a critical bugfix, and with a filesystem eating bug we needed to respond to, that was an unacceptable situation.

I'm waiting for AR glasses to get higher res, but yes.

Also, if we're posting our wishlist - Preonic form factor.

https://drop.com/buy/preonic-mechanical-keyboard

Where do I find a basic vector type? :)

heh, it's really not

what was the NixOS kernel regression?

NixOS and Arch are the two distros that are making the DKMS transition the smoothest.

Doing it right needs lenses (from Swift)

Eh? That's not an open question at all anymore; Rust has a drastically lower defect rate than C and good Rust is every bit as fast as good C.

Now, the engineering effort required to rewrite or redo in Rust, that's a different story of course.

Rust really is attractive to a filesystem developer. Over C, it brings generics for proper data structures, iterators (!), much better type safety, error handling - all the things Rust is good at are things you want.

For me, the things that would make it just perfect would be more ergonomic Cap'n Proto support (eliminate a ton of fiddly code for on disk data structures), and dependent types.

The only thing btrfs took from ZFS was the featureset - COW, data checksumming, snapshots, multi device. ZFS was a much more conservative design, btrfs is based on COW b-trees (with significant downsides) and if you can put it in any lineage it would be Reiserfs.

Jacqueline du Pré played this with fire.

https://www.youtube.com/watch?v=U_yxtaeFuEQ

License isn't a blocker for a microkernel, with the filesystem being a completely separate service.

If someone's interested in working on a port, that'd be an interesting conversation.

Ivory tower is right when you're talking about Linux. I've heard "Linux is for the big tech companies now" enough times to make me gag.

In my experience, the trolls never go away unless you start poking at them to point out how ridiculous and laughable they are.

Well, if you don't include the "why", to you aren't saying anything everyone hasn't heard a thousand times before.

The "why" is important.

That attitude is how you get ahead as an individual at the expense of our whole field.

That's how you end up with decisionmaking that's nothing more than popularity contests and no one even bothering to do the analysis on which option is technically better.

That way leads the death of leadership.

If you want to accomplish something as challenging as a filesystem, you do it by consistently making the right call and sticking to it, over and over and over.

And if you keep doing that, eventually you end up with the most active filesystem community around, and the ability to flip even the kernel community the bird when their weaponized incompetence becomes too much :)

If something's garbage you can just call it garbage, no need to wrap it up in virtue signaling and culture wars.

But please do tell us why it's garbage

That was good for a chuckle

HAH

Not comparable to losing filesystems, sorry...

You could only think Heinlein had militaristic views if that was the only book of his you read.

Read another book of his and you'd think he was a communist, another an anarchist, et cetera.

He liked to explore ideas. If there's one thing that's reasonably consistent across his work, it's his belief in individual agency.

What are they famous for then? High quality, trustworthy code?

It doesn't matter if you want to "tolerate" it if every time there's a filesystem thread there's stories about lost filesystem and unfixed bugs, and the rare times people try to report bugs or issues they go nowhere.

You're ranting about reality, and somehow I doubt you were ever a user of mine.

I've worked hard to establish an engineering community where no one has to be afraid to point out broken shit, including and especially in my code, and I wouldn't want your attitude anywhere near it.

yeah there's no real QA process for the stable trees

the btrfs devs are also famous for being unresponsive to these sorts of issues.

there's a feedback effect: if users know that a filesystem takes these kinds of issues seriously and will drop what they're doing and jump on them, a lot of users will very happily spend the time reporting bugs and working with devs to get it resolved.

people don't like wasting their time on bug reports that go into the void. they do like contributing their time when they know it's going to get their issue fixed and make things better for everyone.

this is why I regularly tell people "FEED ME YOUR BUG REPORTS! I WANT THEM ALL!"

it's just what you have to do if you want your code to be truly bulletproof.

Do you see the same reports about ext4 or XFS?

I don't.

Not inherently.

Early bcachefs was ridiculously fast, it's gotten slower as we've grown all the features to compete with ZFS. All the database stuff that gives us amazing flexibility adds overhead (the btree iterator code has gotten fat), backpointers and modern accounting blew up our journalling overhead. A lot things that we needed for scalability, or hardening/self healing, have added overhead.

COW really isn't the main thing, it's cramming all the features in that we want these days while keeping the fastpaths fast that's the tricky part.

But, a lot of this stuff is fixable - performance just hasn't been the priority, since the actual users aren't complaining about performance and are instead clamoring for things like erasure coding.

(and, the performance numbers that I've seen comparing us to ZFS still put us _significantly faster)

I think this would be the most usable microkernel these days, and yes, it does FS as a service: https://www.redox-os.org/

There's no inherent reason why a filesystem in userspace has to have a measurable performance impact over in-kernel, done right. It would be a lot of engineering work, though.

Context switches aren't that expensive when you're staying on the same core, it's IPIs (waking up a thread on another CPU) that's inherently expensive; and you need zero copy to/from the pagecache, which is tricky. But it totally could be done.