It would be tempting to chalk it up to marginal storage controllers and/or memory or even flaky power supplies. I've seen all three result in very weird and hard to diagnose issues, which presumably a more critical and checksumming filesystem is simply better at sussing out than a more old-fashioned FS like ext4 or XFS.

But from the impression of the type of hardware you're running, I highly doubt that is the case. And of course ZFS would be affected, too.

> And of course ZFS would be affected, too.

In theory, yes. But one of the design goals of ZFS was to be resilient against faulty hardware. On paper that seems an impossible task but I've seen first hand just how impressive it is where I had a faulty raid controller which would randomly disconnect HDDs but only under heavy load. It took weeks to debug this -- it was so bad it actually caused Solaris to crash (which made fault diagnosis all the harder). I then switched to FreeBSD, which was a little more stable so enabled me to get a little more meaningful diagnostics and when I realised what the fault was, I was amazed I hadn't actually lost any data. At one point the fault was so bad it completely trashed the superblock but FreeBSD's ZFS tooling meant I could recover that superblock and the entire outage took all of 10 minutes.

On the flip-side, the few times I've used btrfs I've either been left scratching my head at the confusing tooling, or pulling my hair out because of data loss. On one system, the storage pool -- which literally just consisted of one HDD and no clever raiding -- reverted itself by 6 months. I was an early adopter of ZFS and never ever experienced so much as a blip despite running it on hardware that really should have caused ZFS to go tits up. Yet Btrfs would get it's knickers in a twist on stable hardware.

I get my stories here are purely anecdotal but I her the same kinds of stories crop up over and over again from other people too. So I find it very hard to take Btrfs seriously as a ZFS replacement. But then given ZFS is an older and more mature project and ZFS already works pretty damn well, I also question why anyone would want a replacement to ZFS when they could just use ZFS.

> But then given ZFS is an older and more mature project and ZFS already works pretty damn well, I also question why anyone would want a replacement to ZFS when they could just use ZFS.

Basically just licencing. The great irony is that btrfs was started by Oracle (not sure if they're still involved) before they acquired Sun. A relicensing effort to GPL would probably be better, but, you know, Oracle.

I argued in the past that OpenZFS should have contributors sign a small CLA which permits relicensing to GPL to prepare for this nonetheless, it's a small effort and could save a lot of effort later.

Your experience with a faulty controller mirrors the issues I experienced with the faulty ASM1061 controller; unstable and flaky under load.

Recovery was quite undramatic once the affected disks were put on a known stable controller. Btrfs-check followed by a scrub got everything back in order.

And btrfs gives me one thing that ZFS can't do (yet): a completely flexible RAID1 storage pool where I can add and remove disks as I want, the only limitation being that no one disk can be larger than half the total pool size. For me, this flexibility is a killer feature.

I agree - but in cases of marginal hardware I'd expect to see more strange issues than just specifically FS corruption with btrfs.

At one point it was limited to if I was using compression, but using compression was the major reason I wanted btrfs for that use rather than ext4/xfs.