4 ms·
From the FAQ https://bcachefs.org/FAQ/ https://bcachefs.org/FAQ/ : Bcachefs is safer to use than btrfs and is also shown to outperform zfs in terms of speed an
by jbverschoor 3y ago
From the FAQ https://bcachefs.org/FAQ/ https://bcachefs.org/FAQ/ :
Bcachefs is safer to use than btrfs and is also shown to outperform zfs in terms of speed and reliability
So what makes it more reliable? I can't find a simple overview of the design / reasoning behind the whole thing and what makes it 'better' than the rest.
- dralley 3y agoWell, keep in mind that language has remained unchanged for a few years now. Certainly BcacheFS has some theoretical advantages (lack of write hole etc.) but BTRFS has nonetheless improved since then and BcacheFS has gotten more complex. It's still a very exciting filesystem so I'm sure we'll be seeing third parties test it rigorously very soon.
- kevincox 3y ago> Bcachefs is safer to use than btrfs Citation needed. With a sample size of 1 it ate my data and BTRFS has been running perfectly fine on that system (after I bailed off of bcachefs) and other systems. I think it is great that they consider data safety very important but it will take lots of testing and real-world experience to validate that claim.
- __turbobrew__ 3y ago>Bcachefs is safer to use than btrfs That is a pretty bold claim given that Facebook runs btrfs in prod across the majority of their fleet and almost nobody uses bcachefs.
- MrDrMcCoy 3y agoCould just mean that RAID5/6 isn't broken...
- KennyBlanken 3y agoFacebook et al generally structure their systems to tolerate node failures through redundancy at higher levels. In short: they can not care, or work around, design problems most others can't - or use it for a specific purpose, such as logging, etc. Btrfs was terrible in the early days, took ages to "git gud", and given a filesystem is supposed to be among the most stable code in the OS, that burned a lot of bridges. It wasn't until fairly recently that btrfs could tolerate being completely filled. I have no idea how valid the claims are, but bcache's developer claims that btrfs suffers from a lot of terrible early design decisions that can't be undone. The show-stopper for me is that bcachefs lacks a scrub: > We're still missing scrub support. Scrub's job will be to walk all data in the filesystem and verify checksums, recovery bad data from a good copy if it exists or notifying the user if data is unrecoverable. The only argument I see for btrfs is that it supports throwing random drives into a pool and btrfs magically handles redundancy across them. ...but it doesn't support tiered storage like bcachefs does. We're well past "I want to have a redundant filesystem I can randomly add a drive to and magically my shit is mirrored." These days people want to have a large pile of spinning rust with some SSD in front of it, and doing that in all but ZFS is kind of a pain.
- devit 3y agoCan't you do most of what scrub would do with something like: find . -xdev -print0|xargs -0 cat > /dev/null (ideally replacing cat with something that continues after errors)
- stonogo 3y agoCiting the origin of "move fast and break things" as the exemplar of safety is itself pretty bold.
- Nathanba 3y agoI only read that they use it for their build servers and use the snapshotting feature for quickly resetting the build environments. It's not a common use of a filesystem imo
- Tuna-Fish 3y agoThe bcachefs architecture overview is here: https://bcachefs.org/Architecture/ https://bcachefs.org/Architecture/ The claim for reliability comes from the idea that bcache has been in heavy production use for a decade, and considered rock solid with plenty of testing of corner cases, and that bcachefs builds a filesystem over the bcache block store so that most of the hard things (like locking and such) are managed by the underlying block store, not the bcachefs layer. This way, the filesystem code itself is simple and easy to understand.