On Sat, Aug 09, 2025 at 03:21:56PM -0400, Josef Bacik wrote: > On Sat, Aug 09, 2025 at 01:36:39PM -0400, Kent Overstreet wrote: > > On Thu, Aug 07, 2025 at 07:42:38PM +0700, Aquinas Admin wrote: > > > Generally, this drama is more like a kindergarten. I honestly don't understand > > > why there's such a reaction. It's a management issue, solely a management > > > issue. The fact is that there are plenty of administrative possibilities to > > > resolve this situation. > > > > Yes, this is accurate. I've been getting entirely too many emails from > > Linus about how pissed off everyone is, completely absent of details - > > or anything engineering related, for that matter. Lots of "you need to > > work with us better" - i.e. bend to demands - without being willing to > > put forth an argument that stands to scrutiny. > > > > This isn't high school, and it's not a popularity contest. This is > > engineering, and it's about engineering standards. > > > > Exactly. Which is why the Meta infrastructure is built completely on btrfs and > its features. We have saved billions of dollars in infrastructure costs with the > features and robustness of btrfs. That's great for Facebook, but you're doing everyone else a disservice. The big cloud providers don't require as much reliability from individual nodes. I've provided data in the form of bug reports and actual user reports, you've provided no data on reliability within Facebook, nor which featureset is being used (it's the multi device stuff that's been absolutely notorious; Synology famously still uses md raid to avoid that, write hole and all). This is real, Josef. I've seen time and again how corporate development works; I've been at Google, I've worked with Redhat enough to see their model, and within the filesystem world engineering standards have not been what they should be, and the wider community (i.e. the rest of the world, not just the tech giants) is not being served. COW filesystems were supposed to bring improved reliability over conventional filesystems - it's been known for decades that "update in place" is a massive problem if we want real advances in reliability. ZFS showed that it was possible, but the common consensus in the user community, among people with the data (i.e. quite a few of the distros) is that btrfs dropped the ball, and regressed on reliability from ext4/xfs. That's common knowledge. At this point in the development and deployment in bcachefs I can say, with confidence, that bcachefs is changing that, and that in time we will deliver _better_ reliability than ext4/xfs. That's why my work has been funded, that's what people want, and that's why I'm talking about it.
