[jcalvinowens]

The idea that a brand new filesystem might be more reliable than good 'ol BTRFS, which Facebook runs on basically their entire infrastructure, is downright laughable to me.

Btrfs is also far more reliable than ZFS in my view, because it has far far more real world testing, and is also much more actively developed.

Magical perfect elegant code isn't what makes a good filesystem: real world testing, iteration, and bugfixing is. BTRFS has more of that right now than anything else ever has.

[Tobu]

I've had my own bad experiences with Btrfs (it doesn't behave well when close to full), and my intuition is that Facebook's use of it is in a limited operational domain. It works well for their use case (uploaded media I think?), combined with the way they manage and provision clusters. Letting random users loose on it uncovers a variety of failure modes and fixes are slow to come.

On the other hand, while I haven't used it for /, dipping my toes in bcachefs with recoverable data has been a pleasant experience. Compression, encryption, checksumming, deduplication, easy filesystem resizing, SSD acceleration, ease of adding devices… it's good to have it all in one place.

[jcalvinowens]

> my intuition is that Facebook's use of it is in a limited operational domain

That's not really true: it's deployed across a wide variety of workloads. Not databases, obviously, but reliability concerns have nothing to do with that.

My point isn't "they use it, it must be good": that's silly. My point is that they employ multiple full time engineers dedicated to finding and fixing the bugs in upstream Linux, and because of that, BTRFS is more well tested in practice than anything else out there today.

It doesn't matter how well thought out or "elegant" bcachefs or ZFS are: they don't have a team of full time engineers with access to thousands upon thousands of machines running the filesystem actively fixing bugs. That's what actually matters.

> Compression, encryption, checksumming, deduplication, easy filesystem resizing, SSD acceleration, ease of adding devices... it's good to have it all in one place.

BTRFS does all of that today.

[jeltz]

Why is that laughable? I do not think that it is more reliable than btrfs but it is not a crazy idea either. There are a whole bunch of people in these comments with very recent btrfs reliability issues which have affected them and nobody with recent zfs reliability issues.

[jcalvinowens]

If anecdotes are meaningful (dubious, but I'll play along...), I can counter with mine: I've been running btrfs on bleeding edge kernels for a decade, and I've never seen a single data loss event.

ZFS has corruption bugs, this one was far worse than anything I've seen in btrfs recently: https://lists.freebsd.org/archives/freebsd-stable/2023-Novem...

[tiberious726]

I've been running it on hundreds of servers in prod since once of the lead devs gave a talk at LinuxCon 2014 saying it was good to go. Had a few performance issues here and there, especially on older kernels, but never any data loss

[bjoli]

I also think you can't really compare them: ZFS more or less says "never use without ECC memory". BTRFS is run on just about any potato there is.

I myself would never run a file server without ECC and a UPS configured for a graceful shutdown. I have also never had any issues, but I only have about 10tb of data.