Facebook et al generally structure their systems to tolerate node failures through redundancy at higher levels. In short: they can not care, or work around, des

Facebook 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.