The 6.1 kernel is out
lwn.net
lwn.net
Some other favs:
power management fixes for AMD
big BTRFS perf boosts
ton of embedded controller/fan speed updates
faster retbleed mitigation
usb4 host-to-host improvements
lots of gpu + hid improvements
Fortunately BTRFS allows you to have different RAID levels for data and metadata so you could run RAID 1 for metadata and RAID 5/6 for data."
https://www.reddit.com/r/linux/comments/yrlljv/comment/ivvop...
But FreeNAS is perfect alternative if you don't want to fuck with penguin stuff and just have a blob of storage
BTRFS is the only 'RAID' that I've encountered that will almost predictably fail if forcefully powered off
RAID10 on gen4 NVMe drives, should sync pretty quick, you'd think.
LVM RAID, ZFS, mdadm, all of them are considerably more reliable
I can hear lamenting already: "that's not normal! you shouldn't expect consistency here!"
I tested this because reality says we do unusual things all of the time, don't hate me - hate the results.
Other implementations are demonstrably more robust
Btrfs raid is stupid reliable, if you dont f it up & dont put metadata in raid5/6.
Having checksum consistency & checkpoints is a superpower most of the alternatives dont have. Btrfs is much more flexible about adding/removing drives, of various sizes even, to a raid pool, as compared to zfs, & is imo ridiculously easier to operate, from not needing out of tree modules to just requiring a lot less specialist knowledge in general of different zfs caches for tuning/setup. There's no alternative close & it runs great across millions of systems, with operators such as Facebook/Meta.
I'm sorry to offend what is otherwise a decent filesystem, but I, and the systems I'm responsible for, will not use BTRFS with RAID and this characteristic.
There's a lot of qualification there, read it again.
I would much rather let the journal replay and do its thing, than rebuild the array. Something every alternative offers, consistently.
BTRFS RAID has routinely burned me every time I have given it the opportunity. It hasn't survived nearly as much as the other test arrays.
I'm fine discussing filesystems, benefits, and all of that - but I can't entertain it when you try to make this so heated.
These are anecdotes from reliability tests I've been doing... I'm sharing them so that they can be considered.
You accuse me, while opening like this? At least my anecdotes weren't insulting.
edit: To add, this isn't something I've kept secret. I don't know why you say that. Have you read every communication I've written?
I can show you screenshots that span the last three months discussing this exact situation
I haven't reported it upstream because I have better things to do; ship.
You might see this, but hopes aren't high. This is about the response I expected. It's an extreme edge case, but it consistently cuts.
The filesystem we use is incredibly uninteresting. By design.
I find it utterly hilarious you think I'm the only person who has had issues with BTRFS RAID
It ignores so many use cases and financial realities.
edit You probably meant more broadly in the FOSS ecosystem. Personally I'm not worried about that as GCC seems to be doing ok competing with Clang on technical grounds. For instance, last I heard GCC was ahead of Clang in support for new C++ features.
Clang is suffering because Google is off on a chase for "Carbon", which hasn't been abandoned yet, so neglects all but LLVM.
This doesn't affect the kernel much, because the C parser needs little attention. The Clang project needs someone not Google to step up.
I was going to mention Apple but they're famously prone to adopting non-mainstream languages like Swift. I don't think they have much interested in modern C++ features.
So there is already a monoculture in some circles.
However there's plenty of custom gcc toolchains for embedded systems. It isn't going anywhere for a while yet.
Even if clang was a "first-class citizen" compiler for the kernel and was picked up by some big distros, there's an absolutely gigantic market of companies designing and building embedded systems around GCC. There already is a LLVM/Clang monoculture in some areas (e.g. research, "modern" C++ shops), but while I don't have the numbers or anything, I'd imagine that those fields make up a very small percentage of worldwide C/C++ developers. A lot of those boring embedded systems companies have low margins and don't think particularly highly of software developers, so they'd never consider refactoring all of their tooling and projects to use clang unless they absolutely had to.
If the kernel _dropped_ support for GCC, you might see an actual monoculture develop. But I don't see the kernel _supporting_ GCC, or particular distros choosing to build their kernel with it, making any real dent in the huge market share (for lack of a better term) that GCC has built up. It might seem that way if you read HN and talk to people working in SV, but GCC is still pretty ubiquitous.
Lots of people _use_ Apple’s developer tools, Google Chrome and other Google products. But in each of those cases, I believe the actual group of people directly dealing with C++ and Clang are small relative to the global C/C++ developer population. Android has a strong argument since Google can force the hands of OEMs. I don’t see how the size of Chrome’s user base will bring about an LLVM monoculture if 99.999% of C++ developers on earth never build Chrome themselves.
The majority of electronic devices on earth have (non-Android) firmware or software written in C/C++, written by people all over the world who don’t work for Google, Apple or anyone you’d even consider a tech company. You will never hear about these projects on HN because they’re closed-source, proprietary and (frankly) boring. But almost all of those projects use whatever toolchain their vendor provides, and more often than not (in my experience), thats GCC.
Like I said, I don’t have any numbers to back this up. I’m not claiming that GCC reigns supreme and that LLVM is irrelevant outside of academia. I’m just saying that if you’re really concerned about LLVM _support_ in the kernel leading to an LLVM monoculture, you might not understand how widely used GCC is in “boring” tech.
[edit] Adding to this, I guess it also depends on how you view a “monoculture” w.r.t compilers. I could imagine a not-too-distant future where LLVM gets the vast majority of research effort, and you see cool new optimizations brought into it while GCC stagnates. We’re arguably already there. But I don’t see that driving thousands of low-margin hardware OEMs to switch over from GCC to LLVM. Maybe that will happen one day, but I think we’re pretty far away from that.
I personnaly think it's too much mostly because I don't value most of the reasons Debian patches (I don't care about exotic architectures - I value conformance to upstream more than the ability to have modular and small packages - I don't care about having some non-free parts in my package).
Want an easy path to use new snapdragon arm chips.