koverstreet

8 ms·

91.
by koverstreet 10mo ago
Speaking for myself, Valve has been great to work with - chill, and they bring real technical focus. It's still engineers running the show there, and they're good at what they do. A real breath of fresh air from much of the tech w
92.
by koverstreet 10mo ago
For on disk data structures, yes. LSM-trees do really badly at multithreaded update workloads, and compaction overhead is really problematic when there isn't much update locality. On the other hand, having most of your index be constan
93.
by koverstreet 10mo ago
We're talking about database performance here, not deployment numbers. And personally, I don't much care what Meta does, they're not pushing the envelope on reliability anywhere that I know of.
94.
by koverstreet 10mo ago
bcachefs's btree still beats the pants off of the entire rocksdb lineage :)
95.
by koverstreet 10mo ago
I haven't looked at fs-verity at all, but per-file merkle trees should definitely be built into the filesystem as a standard thing. Rsync and file transfer programs want it, and having to compute that every time is crap - if it's
96.
by koverstreet 10mo ago
ZFS is the only filesystem I know of with one, and theirs is pretty incomplete. It does need to be a shared project.
97.
by koverstreet 10mo ago
That does happen sometimes. But look on the bright side; a lot of people are getting crash courses in low level systems debugging, and those are skills that are not as common as they used to be - but they're still important. If you loo
98.
by koverstreet 10mo ago
You can do that now via the data_allowed parameter ZFS did a bunch of stuff right, it's just a much older design; pre-extents, and based on the original Unix filesystem design - filesystem as a database was still unproven at the time.
99.
by koverstreet 10mo ago
The default should be the device's native blocksize, and some devices misreport. You also lose performance if you use a larger blocksize than necessary. If we can, I'd like to get a quirks list in place, but there have been higher
100.
by koverstreet 10mo ago
yeah, we'll be supporting 6.18 ongoing.
101.
by koverstreet 10mo ago
Still changing the on disk format as required, but we're at the point now where the end user impact should be negligible - and we aren't doing big changes. Just after reconcile, I landed a patch series to automatically run recover
102.
by koverstreet 10mo ago
Distros generally build everything they can as modules these days, including filesystems. No reason not too, we've had initramfs since forever; you can't build everything in that anyone might need to boot their machine. As long as
103.
by koverstreet 10mo ago
I'm here to talk filesystems and technical topics, not to take part in or stir up drama. There's been more than enough of that. This is hacker news, not drama queen news :)
104.
by koverstreet 10mo ago
It'll happen eventually, it's been a frequently asked for feature.
105.
by koverstreet 10mo ago
yes, it will. But we do want to communicate properly with systemd and let the user know what's going on if mount has to take awhile because of some sort of recovery (instead of timing out), and various other things. related, plymouth i
106.
by koverstreet 10mo ago
Do Arch and NixOS count? We're in the core package repositories for them, and have packages available for a list of others. We're not aiming to be in GUI installers yet, that'll be sometime after taking the experimental label
107.
by koverstreet 10mo ago
Scrub went in in 6.15. I think 6.17 might've been when it was fully solid; it took a bit for some bugs to shake out in the self healing paths.
108.
by koverstreet 10mo ago
I'm hoping to have erasure coding done sometime in the first half of next year (knock on wood). While reconcile was getting done we got a detailed outline of where EC resilvering is going to plug into that, so it's not looking lik
109.
by koverstreet 10mo ago
How long ago was this? We've been cranking through bugs fast, and there are still bug reports coming in but the severity and frequency has declined drastically, while the userbase has gone up; polling the userbase it's been stabil
110.
by koverstreet 10mo ago
Oh cool. Happy to answer questions about all things bcachefs or what-have-you. just please no more questions about whether or not bcachefs will be in the kernel, I've been asked that enough :)
111.
by koverstreet 11mo ago
FAANG engineeers can't code for shit, but the one thing they did get right was when they jumped on the Rust bandwagon
112.
by koverstreet 11mo ago
I also don't recall anyone ever blaming the WWII, or other generations like this. Boomers coasted off the success of the postwar era, and now we're all poorer for it.
113.
Bcachefs_metadata_version_reconcile(patreon.com)
3 points by koverstreet 11mo ago|0 comments
114.
by koverstreet 1y ago
soon :)
115.
by koverstreet 1y ago
It's been moving slowly at first because you need a lot of bindings done before you can do interesting work, and bindings/FFI tend to be fiddly, error prone things that you want to take your time on and get right - that's whe
116.
by koverstreet 1y ago
"Experiment" is a misnomer. Rust has been around long enough and demonstrated more than enough real advantages in writing reliable code that we know it's what we want to be doing.
117.
by koverstreet 1y ago
> Please please don't forget I want you to succeed - that's why I bunged nearly $800 your way in this endeavour - but I'm not the only person who thinks you come across as completely immune to critisicm, even when it'
118.
by koverstreet 1y ago
Look, it wasn't just this one thing. There had been entirely too many arguments over bugfixes, with the sole justification on Linus's end being "it's experimental garbage that no one should be using". I can't s
119.
by koverstreet 1y ago
> Concerns about general policy need to be handled separately from individual cases. Citation needed. > Linus's job is not to make the very next version of the kernel as good as it can be. It's to keep the whole system of Li
120.
by koverstreet 1y ago
> It seems like bcachefs would benefit from parallel development spirals, where unproven code is guarded by experimental flags and recommended only for users who are prepared to monitor and apply patches outside of the main kernel releas

More ›