Bcachefs Might Be Ready For Upstreaming In Linux This Year

[flower]

Is Raid5/6 planned in Bcachefs?

it already has. it's called erasure code and you can enable it even for folders.

[vladpetric]

If I'm reading this correctly, BTRFS with RAID 5/6 has the write hole problem and it hasn't been fixed (I don't think it's possible to fix it without a bit of redesign honestly, but I could be wrong).

https://btrfs.wiki.kernel.org/index.php/RAID56

ZFS RAIDZ doesn't have that problem ...

[vladpetric]

It's not that RAID5/6 "ON btrfs" fundamentally broken ... it's just not high enough on priority lists.
But otherwise yes, RAID5/6 is fundamentally broken ...

No datacenter with serious amount of data is going to be using RAID5/6 anyway, because with larger disk sizes, it is becoming increasingly likely, that a RAID5 array does not survive a rebuild anyway. Cloud providers and backupers (Backblaze) have built their own distrubuted file systems.

I don't think implementing RAID5/6 for btrfs is even worth the effort. People are free to use md-raid and ZFS while the RAID5/6 concept still lasts.
There's no real market for RAID5 anyway ... except Linux nerds in their garages, who would then blame it on btrfs, when their RAID arrays wouldn't rebuild, even if it was due to real errors on their crappy 10-year old SATA drives bought garage sale.

No, it's not worth it. There's plenty of other useful features that are worth more effort than RAID5.

Honestly I had to start a slur about RAID5/6 at a previous company so that they stop doing it for massive production data (mdraid ... ). I don't know if I was successful, I left a while back. So yeah, I generally agree with everything you're saying, but:

BTRFS pushed RAID5/6 while IMO it has always been a broken feature https://btrfs.wiki.kernel.org/index.php/RAID56

That to me is quite problematic.

[Draget]

I was an early adopter of BTRFS (and ZFS for that matter, back to ZoL Fuse) for years and have been burned several times. Most things worked really well and perfect as long as the environment was as expected. But actually coming across flaky hardware, memory errors, end-of-space situations, upgrades etc. it turned out to be very fragile and tend to randomly explode.

Even right now on my ECC-backed, enterprise-disk homeserver I have two old btrfs disks that seemed have a broken free disk space cache, not fixed by a scrub.

Don't get me wrong, BTRFS is a really awesome filesystem and it has come a long way. But it takes time and some battlescars for a filesystem to prove itself. Things the dev simply does not come across in their setup. I am really looking forward to play more with bcachefs and it being included in the kernel, but it will take years before I seriously trust critical data to it.

[LinAdmin]

There are still a bunch of severe bugs in bcache that haven't been fixed for years, anyone jumping on bcachefs straight away is just asking to repeat the early btrfs experience.

It's a single dev, working on a filesystem with about as many features as ZFS - calm your expectations

I do not understand why he started snapshots before the code repairing faulty sectors of Raid-1 and for scubbing was perfectly realized.

[LinAdmin]

It depends on the reason: if they had not been fixed because a major rewrite of some related subsystem is planned that would make sense in an experimental fs.

IMHO the author was more interested in self-fulfillment...

[LinAdmin]

I've been using bcachefs since around 2018. The only problems I've run into were either fixed that day, or were caused by me not upgrading the filesystem versions properly. If anyone wants some quick and dirty tests I think I can find an SSD lying around.

IMO the biggest missing feature right now is scrubbing: https://bcachefs.org/bcachefs-princi...-operation.pdf
image_1866.png

Not only scrubbing is missing, but also automatic repair in case any reading detects a mismatch of crc.

[anarki2]

Really looking forward to seeing the release, especially fond of Kent's attitude in developing bcachefs (i.e. get the core design principles right before releasing it).

He doesn't really have other choices as it's been rejected before lol.

[lyamc]

Not only scrubbing is missing, but also automatic repair in case any reading detects a mismatch of crc.

True, but I also understand why: easier to add after. There's also been ongoing discussions on how to best implement scrubbing: https://lwn.net/Articles/754504/

Dave Chinner wondered if there was a way to have a single scrubbing command that handled any kind of filesystem, so that users do not have to remember how to do it for each type. No one seemed opposed to the idea but getting there may take some time.

[LinAdmin]

True, but I also understand why: easier to add after. There's also been ongoing discussions on how to best implement scrubbing: https://lwn.net/Articles/754504/

Many thanks for your interesting link.
However, I am still convinced that the best way to proceed would be:

a) Determine the on disk data structures for all planned features.
b) Realize the most basic functionality of writing, reading and changing files.
c) Implement data repair in case that reading shows crc-errors.
d) Implement scrubbing.

At this point the code would be ready for mainlining.
This will bring the test coverage that can not be obtained by own testing.

e) Implement remaining functionality like snapshots.