linux-kernel - Re: [GIT PULL] bcachefs changes for 6.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2z3wpodivsysxhxmkk452pa4zrwxsu5jk64iqazwdzkh3rmg5y@xxtklrrebip2>
Date: Sat, 9 Aug 2025 16:37:51 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Josef Bacik <josef@...icpanda.com>
Cc: Aquinas Admin <admin@...inas.su>, 
	Malte Schröder <malte.schroeder@...ip.de>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	"Carl E. Thompson" <list-bcachefs@...lthompson.net>, linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs changes for 6.17

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.