Allocator Hints for Btrfs
wiki.tnonline.net
wiki.tnonline.net
I know BTRFS is the default FS for a bunch of distros now, but I haven't heard much about it in the RAID space. Most people seem to use ZFS, despite the massive memory pressure it adds, because of fear of bugs and reports of filesystem corruption years ago. Perhaps someone who uses BTRFS for RAID can comment on how well BTRFS RAID works these days?
I ran into Btrfs RAID6 corruption myself about ten years ago. Though to btrfs's credit, I didn't lose any data: the filesystem only locked up read-only on me. But this time I'll take their word on unstable.
It's never been RAID1 it's the odness of the pid decides which disk to read from.
For raid5/6 I dont use the built in raid, but mdraid. I stopped waiting for btrfs raid56 to stabilise.
One advantage with these patches compared to using dm-cache, lvmcache or bcache is that everything is native Btrfs and fully compatible with non-patched kernels (though the 'hints' won't apply for new writes). Btrfs allows for adding additional devices to existing filesystems, so no mkfs and data-shuffling is needed. If you do not like the result, simply set default hint (type 0). You can then "btrfs device remove" your previously added SSD/NVMe devices.
And a few years before that Ubuntu backports had Ubuntu specific ZFS corruption.
Basically the old truth still holds with checksummed filesystems too: raid is not backup
This btrfs feature only supports having the data chunks prioritize the HDDs.
Whether or not that matters depends on your use case of course: it's not worse than a RAID setup of only HDD. I'm using bcachefs on budget gaming PCs built from old spare parts, so having a small SSD and a bunch of HDDs for games is great.
I'm taking the experimental label off in 6.16, so it'd be nice to avoid the drama and have a smooth release :)
(also, fun to see btrfs copying bcachefs)
Keep in mind though I wrote all that ~10 years ago, and it was very much an opinionated mission statement. bcachefs started out 15 years ago as a couple of us sitting around in the office drinking beers "you know, this looks like a really elegant basis for a filesystem, it's going to be way smaller and cleaner!" (talking utter shit, of course). But, somehow, I stuck with it...
I don't see anything there that's fundamentally changed. Btrfs repair code is still quite weak, and "btrfs ate my data" stories have reduced somewhat, but I'm still seeing them come up, and the core architectural issues haven't changed. Josef was recently saying on lkml that they (the btrfs team, at least at facebook) have accepted that XFS will always be better in many scenarios, and to me that's an admission of failure - a COW filesystem should work just as well as a previous generation non-COW filesystem in nocow mode.
A mission statement like that is fundamentally saying "these are my priorities, this is why we need to do better" and I stand by what I wrote, because taking on writing a new filesystem - the part of the operating system with the highest requirements for "this absolutely has to work" robustness - really is about having the right priorities.
Gotta take your time your time to get things right, make sure the fundamentals are solid, before chasing all the features - this isn't an area where typical silicon valley "go big or go home, fake it till you make it" attitudes can work.
Yes, I rather think that's the point. And this is clearly the point at the party where I find an excuse to move on from the very earnest person who's decided that something is wrong on the internet and say "sure man...good luck with that".
Good luck with that.