What I’ve read looks good but it’s going to need a track record of reliability before I’d trust it.
it’s going to need a track record of reliability before I’d trust it.
That’s why kernel inclusion is so important: People can start testing it without jumping through hoops of manually patching and compiling the kernel.
Curious too. I tried running bcachefs last year and with the combination of compression and encryption everything ended up corrupted very very fast.
Did you find the root cause of the corruption?
It was a known bug, I assume it is fixed now that Linus merged it.
Why? BTRFS never did, and it’s used by a lot of people.
I only read the wiki article and honestly, I can’t tell what makes that different from other “advanced” FSs like BTRFS and ZFS.
Could someone get me up to speed here?
Compared to btrfs it’s claimed to be faster and having working RAID support. Its unique feature is using a fast device as cache to speed up access to slower, larger disks, I think.
Yes. The intelligent multi-device-type feature is a huge improvement for any workload that needs more space than what an SSD can affordably provide, even moreso with the reliability of eg RAID1.
Before that I had to use BTRFS (RAID1) on bcache (not fs) devices, but half of the cache space was being wasted on the redundant copies because the two systems operate independently.
To explain in case someone doesn’t know what this means, it’s something BTRFS doesn’t have (and AFAIK isn’t even on the roadmap). It means you could have, say, an SSD and a more reliable HDD RAIDed such that every stripe on the HDD counts as multiple writes; and you might set that system up so that the SSD is read with priority, and the HDD is written in the background, so that - even though you have a slow drive in the RAID, throughput happens at the faster SSD speeds.
The average user probably won’t use this much, but there are all sorts of ways this could be leveraged, by companies, self-hosters, smart OS installation scripts, even removable drive mounters, like udiskie.
Compared to btrfs, it has native encryption too - though it’s said to be unaudited at the moment. Btrfs needs dmcrypt for encryption support.
What are the actual differences between native encryption and dmcrypt? Like: Can it be booted? Does it leak more information about the fs? Is it faster?
Native encryption is when the filesystem driver does the decryption in addition to the regular decoding job. Dmcrypt is where encryption is done by a separate component that’s part of the kernel. Dmcrypt decrypts the raw block device (partition) and creates an unencrypted virtual block device (usually in /dev/mapper/). The filesystem driver then decodes this virtual device to give the final data access. It’s like having a filesystem within a filesystem.
Regular bootloaders like Grub can’t decrypt anything. So the /boot device is usually on a separate unencrypted partition. You need the initramfs to be able to decrypt and decode the partition. That’s not very complicated - most users don’t even need to deal with it.
Dmcrypt is arguably more secure than native encryption, since you won’t know the filesystem type until you decrypt the partition first. On the other hand, native encryption is likely to be faster and more flexible for complex filesystems like ZFS, Btrfs and BCachefs.
Compared to ZFS, it’s a sideways movement except for being in the kernel. ZFS has a lot more enterprise level features and an excellent track record. Its used widely for some pretty big installations, and still can be used by the homelabber quite nicely. Things like
fs sendand native encryption are big.Compared to BTRFS, well, it’s definitely an improvement in many areas for a driver that’s in the kernel.
The story behind bcachefs development is mildly wild.
Where can I find the story behind it? This is the first I’ve heard of it
I don’t know of anything that documents it as well as reading the literal mailing list responses at each time it became relevant.
But the actual development story isn’t that interesting other than when some extremely unprofessional behavior from a lot of parties occurred.
Like actual piss baby anti social nerd shit.
Sorry, I don’t know if it is documented anywhere, but in summary the project started with bcache (block cache) from a single developer (Kent Overstreet A.K.A Evil Pie Pirate) in 2010 that explained he was building a module for the Linux Kernel.
Bcache is a method of using a fast ssd drive as a caching mechanism for slow but large hdds. As is, the project was quite ambitious but then, when the developer was working in an evolution of bcache (kind-of lessons learned re-implementation), the project grew into a general-purpose POSIX filesystem.
Considering the origins of the most popular file system implementations, expecting a single individual being successful creating a general-purpose one sounded over ambitious.
Then in 2013, out of the blue, Kent left Google to solely work in this project. (In reality though, he spent two years later in Datera as well.)
Then, how do you finance a single developer for a file system from 2013 onwards up to today, when it finally merged into the kernel?
Patreon. The whole thing was financed through it.
That said, there are other collaborators like Daniel Hill, Dave Chinner or Brian Foster, yet what’s surprising is how this started as a side project and eventually became the main competitor of corporate-developed file systems by Patreon funding.
Note: A bit of hype-control here, btrfs which would be the main “competitor” was merged into kernel 14 years ago, so bcachefs still has a long way to go before we can trust it with our data.
Does Bcachefs come with any guarantees regarding my wife’s wellbeing?
If not, I’m definitively sticking with my OpenZFS.
Depends… you didn’t write ReiserFS, did you?
🤣
Finally!
Happy happy joy! I’ve been using it for a year already, as it is simpler to manage than luks + lvm + bcache + whatever FS.
It has been entirely unproblematic through frequent kernel upgrades; caching, background compression and encryption just work.
I’m very glad it made it in; it deserves wider adoption.
Wow, didn’t expect it to happen so soon!
It’s going to be a while before 6.7 is released.
Two months.
Well yes, but seeing the history it has, I thought it would go through some more hiccups along the way, so it would actually take way more than that.
I’m glad to see I was wrong!
The long wait is over!
