- cross-posted to:
- linux@programming.dev
- linux@lemmy.world
- cross-posted to:
- linux@programming.dev
- linux@lemmy.world
cross-posted from: https://lemmy.world/post/4930979
Bcachefs making progress towards getting included in the kernel. My dream of having a Linux native RAID5 capable filesystem is getting closer to reality.
This is the best summary I could come up with:
While Bcachefs was not merged for the Linux 6.6 cycle with one of the concerns raised by Linus Torvalds being that it hadn’t been vetted via the “linux-next” staging area, that process has now begun to raise hopes of potentially seeing the new file-system driver introduced for Linux 6.7.
Overnight the Bcachefs file-system driver was added to the Linux-Next tree as that loose testing area of experimental code that hopes to get into the “next” kernel cycle.
The Bcachefs Git repository is now being pulled into Linux-Next to allow more eyes on the code and all of the automated build/test infrastructure leveraged by various individuals and vendors for testing this leading edge “-next” code.
Having Bcachefs in Linux-Next will lead to much more build testing of the code in different environments and ideally help uncover any lingering bugs before the next Linux kernel merge window opens up in about two months.
So for those interested, Bcachefs is in linux-next.
The original article contains 159 words, the summary contains 159 words. Saved 0%. I’m a bot and I’m open source!
This is the best summary I could come up with:
[…]
The original article contains 159 words, the summary contains 159 words. Saved 0%.
You tried, bot. You tried.
So excited. The multi tiered storage feature is incredibly useful. Add in some cheap SMR as your lowest tier and you got a very cheap very big pool.
That’s definitely an awesome feature. As someone who’s spent a small fortune running an all-SSD ZFS RaidZ array, I could have used such a feature two months ago.
I vow from this point forward to always pronounce it, BEE-ka-chefs.
I much prefer the name of another filesystem, “butterface”
I think it is BEE-kash-eff-ess
deleted by creator
Has somebody a proper comparison with BTRFS and why somebody who is using BTRFS should look into bcachefs?
Last I checked btrfs raid 5 and 6 support was still not declared as stable.
Neither is the support in bcachefs apparently. Erasure coding which is used for RAID 5 is marked as unstable
I’m wondering the same.
This would have been really nice to have a decade ago. In the age of virtualization, what’s the use case?
EDIT: I’m not asking rhetorically. It really would have been nice to have 10 years ago for my use cases. What use cases do you envision for bcachefs in 2023?
a striped hot ssd cache for a massive raided backend on a VM host - all done with native filesystem support sounds pretty good to me.
deleted by creator
You’re running local storage for a VM host? Or are you talking more like whiteboxing your own NAS?
I understand what bcachefs does. I’ve used bcache many years ago to do exactly what you’re describing, albeit for bare metal servers. I’m asking why.
I’m just trying to understand what the use case would be in 2023 outside of a home lab, given that cost per gigabyte is basically at parity between SSDs and HDDs when you consider TCO (i.e. when you price in the extra power and cooling overhead for the HDDs, failure rates, and such).
I have a pretty strong usecase for distributed Small/Medium Business bare metal VM hosts. most locations do not need NAS/SAN, and DAS will more than suffice. lower cost hardware with a near-line raided backend and SSD hotcache at FS level seems to be a pretty decent sweet spot.
obviously this is not some enterprise grade setup and YMMV, but I am pretty interested in a all-in-one FS solution. I am sure others may have more innovative setups where its even more interesting.
Sounds like a great use case.
I’m assuming your nearline drives speak SAS? Are you doing redundant controllers on the backplane for multipathing and for fault tolerance? I’m not sure if bcachefs specifically supports it (or if that would happen at a different layer) but distros in general should support it.
TCO gets split into CAPEX and OPEX, so you come out ahead on the initial purchase even though it uses more power in the long run, which surely looks better to the business.
deleted by creator