HNHacker News
TopNewBestAskShowJobs

koverstreet

2,109 karma · joined July 30, 2012

submissionscomments
koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
The kernel doesn't have any kind of coherent testing strategy. That was a big part of the problem, because that means the subsystems that do test their code, like bcachefs, get stuck picking up the slack for the subsystems that don't.

I was spending a lot of my time just doing QA for the rest of the kernel.

You seem to just be painfully misinformed - or you're outright trolling.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
People keep saying it takes 10 years, but that presupposes methods that never improve. Why would we keep doing the same thing over and over again? Wouldn't be much point in that.
koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
If you want to be a filesystem maintainer, you start out by doing the work involved.

I'm afraid not all opinions are created equal, this isn't design by committee :)

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
There's always one of two of you rabble going "You dared defy the kernel community! You dared defy Linus! Rabble rabble rabble!"

Meanwhile, I no longer have to stress about whether I'll be about to get bugfixes out, actual users seem happy and my life is far better :)

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
It's hard to show with any accuracy how likely a filesystem is to not break when the SHTF or something weird happens, or if they've handled all the weird corner cases, with any kind of automated test.

For that you have to dig into the methodology, look at the code, look at user reports, etc.

But you can get a pretty good approximation just from the philosophies and attitudes of the engineers and what they're talking about.

The talk I just gave at the Rust for Linux conference was all about that - how do we make the system debugable, the community aspect of how we respond to bug reports and talk to users, the prep work for the Rust conversion and formal verification and how we're approaching all that.

Reliability doesn't come out of nowhere, "all bugs are shallow with enough eyeballs" really doesn't apply to filesystems. You just have to plan for it, come up with a methodology, and do the work.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
Within the last year? I think bcachefs is going to be overtaking btrfs soon on active developers, from the trends I saw in the commit logs
koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
Uhh, do you know what the upstream stance is on testing and fixing bugs?

I doubt there'd be any real interest in a bastardized fork that only exists so the deep pocketed vendors can get away with code dump and run.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
Yes, has been for awhile
koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
NixOS thoroughly solves all the external module fragility. They also do distro level CI testing.
koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
No urgency over fixing bugs? What do you think this is, btrfs? :)

All this has been discussed to death, we don't need people armchair quarterbacking a year later. It's over, it's time to move on.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
bcachefs on Arch is a bit better supported, we have the distro package maintainer in the bcachefs IRC channel, and I've never lagged on mainline support like ZFS has.

Actual distro support, and doing it right with people actually communicating with each other, has always been a priority for the project.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
I think the Phoronix test suite does pretty well for the end user who wants something easy to digest; the exact choice of benchmarks is sometimes odd but the harness itself is quite good.

At some point I'd like to get our own automated pts runs going, since Michael is not consistent with what hardware he tests on and he hasn't been consistent with getting them out.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
If you have "refine until it's perfect and don't screw with things you don't understand" thoroughly ingrained, along with the dangers of overconfidence, you'll do fine with AI.

Not everyone gets it though, that's for sure.

And, if you want to know if it's mature, I'd trust the user reports over the one liners :)

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
NixOS. You can't go wrong.
koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
Speaking as someone who consumes this, I appreciate how it's laid out. As a developer, we can often see at a glance where the bottleneck is if we have enough data laid out - IOW, data overload for you is me feeling like a kid in a candy store.

Sometimes there are ways to make things easier without dumbing them down, but way too many people conflate the two; I get nervous when non engineers say "I've studied this, it should be easy".

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
Appreciate it :)
koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
I'd really appreciate it if we could drop the FUD over contribution rules. There are no such rules, it is explicitly Linus's way or the highway, and I already replied to that elsewhere.

And it went in when it did because Redhat was pushing for it and claiming to be supportive - but that never materialized. They wanted to get something for free without investing, or putting in the absolute bare minimum.

A _lot_ of people were saying publicly and privately "dear god yes we need something better than btrfs" - but no one from the existing kernel community was interested in stepping up.

Community's still growing, though. A lot of people have gotten active in making sure bcachefs actually works well for people end to end, and there's a hell of a lot more to shipping a filesystem than just writing kernel code.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
Meta doesn't have anyone working on btrfs anymore, it appears to be two guys at SuSE and drive bys.
koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
I was very up front about where we were at.

A lot of things were tried, people did try to mediate.

The particularly galling thing though was when I finally started looking - post split - comparing bcachefs PRs to other subsystems and especially XFS - I was being more conservative with what I considered a critical bugfix.

There was never a clear statement on what the issue was. What you guys got in public was about as much as I got.

All I can say is - going fast when you're stabilizing and getting bugfixes out the door is what you can and should be doing when you've invested in test coverage, test automation, keeping the codebase clean and asserted, and building up a community that works well together on testing and shaking things out.

I genuinely do not know what they were thinking.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
It really does.

But you might want to check out the bus factor on btrfs too; when a maintainer says "but we've saved Facebook billions and billions of dollars!", calls for the other filesystem maintainer to be ejected from the community, then quits to join Anthropic a month later - that's not a vote of confidence.

I'd be very happy if people could just stop bringing up drama and us factors. We put it behind us a year ago, but it seems not everyone got the memo.

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
I went back and forth with Hetzner a couple times, I think we just got a bad machine :)

I've been saying it for months, but eventually I'm going to move the automated builds off the 48 core monster and we'll be able to use that for automated perf testing too. The machine we just got has spindles for EC perf testing, but the Hetzner monster has very high end enterprise ssdd.

Also, just got done with the Rust for Linux conference, still not home but here's slides that still need reformatting: https://evilpiepirate.org/~kent/Kangrejos-2026-bcachefs.pdf

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
It's just been a lot less drama within the project since the split.

I do have a lot more pull requests to merge than I did before. I don't know if you want to count "Kent isn't reviewing PRs fast enough" as drama :)

koverstreet··on Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
Why do people keep bringing up drama?

The community infighting has sucked, but that's a thing that matters primarily for maintainers.

I think most users just want something that works.

koverstreet··on Everyone should slow down AI development except for me
Yeah, they won't.

And if a threat to the human race does come from AI, it's going to come from OpenAI/Anthropic. Hypercapitalist, secretive, in bed with the government, plus multiple real documented hackings of open source infrastructure already.

We're a hell of a lot safer with China doing the same research out in the open and making it available to anyone. The choice might well be: one or two superintelligent autonomous AIs at OpenAI/Anthropic - or a lot of smaller ones, unable to be controlled but also coming out of a diverse set of environments.

One of those leads to a stable ecosystem where we can all coexist, the other is genuinely terrifying. But make no mistake, from OpenAI/Anthropic this is all motivated by their stock price - when you're in the silicon valley mindset, it distorts your reality. They've convinced themselves that everyone's safer if they stay on top and in control, conveniently ignoring how that benefits them, and I don't believe them for a minute.

koverstreet··on Everyone should slow down AI development except for me
Who should I be more scared of? China, which has been doubling down on open transparent research, or the secretive US companies who are in bed with the most unhinged administration we've ever had and has been actively starting wars?

They're not proposing anything concrete, and when they do, what do you think the proposal will be? Will OpenAI and Anthropic open themselves for inspection so we can verify they really have stopped developing these "world ending" technologies? Or are their proposals going to be aimed at everyone running open Chinese models?

koverstreet··on Everyone should slow down AI development except for me
"Trust us, really!"

HAH

koverstreet··on Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
Yeah, I'm with Theo on this one. Conventional OS security between Ring-0 and everything else is well understood; the problem has become too much code in Ring-0, a great fraction of which has its own interfaces across the security boundary, and the Unix security model just doesn't scale.

No capabilities, or even a sane and useful way of adding capabilities with everything in ring 0, and the flat integer namespacing of users and groups just doesn't work for what userspace needs to do today - hence namespaces, which have introduced their own problems, because (no surprise) trying to graft a tree structure onto a flat integer namespace after the fact is a mess.

Virtualization tried to sidestep all that, but to make it fast the cost has been more driver interfaces to host ring-0 - remember what the original was? - and screwing around a whole bunch with particularly arcane facets of the core ring-0 security boundary, e.g. page tables.

It is a mess.

koverstreet··on Xiaomi: New CPU matches Apple cores single threaded, much faster multithreaded
Instead of railing about ideology, try comparing the actions of the U.S. and China over the past 20 years. The U.S. has been far more interventionist and aggressive; China appears to be maturing and the U.S. is regressing.
koverstreet··on RISC-V: They Should Have Known Better
I consistently see a level of competence and professionalism in South America that has left the building in the states.
koverstreet··on DeepSeek pause fundraise after comments on compute gap to US leaked (transcript) [pdf]
The maturity of leadership in China seems to be on a whole different level from the U.S.

Lots of companies in the U.S. have fallen victim to that syndrome, but if you used the word "restraint" in that context in Silicon Valley most people would look at you like you're insane.

Page 1 of 19Next →