Sure. Our small ~500GB volume (on an OpenSuse system) became essentially read-only with ~50GB of free space on it. The error code was no free space. We clearly didn't have the "toolkit" needed to deal with such an issue. The box was a secured system, so we couldn't add an additional device easily (non-keyboard USB devices were disabled in the kernel, for example). Also, the read speed off the volume became terribly slow...it would've taken days to get the data off the device. We tried many commands to try to unbork the volume, with no luck. Even some of the btrfs commands were taking hours to run and became unkillable. We had to reboot the box several times...

We had a 24 hr old copy of the data and we were able to lift the few very important modified files off the device. So we reformatted with XFS and were able to restore the volume to a working state.

Fortunately, the failure happened late on a Friday so we had the weekend to put it all back together again.

I have only hatred for btrfs. Complete crap. Only our business competitors should use it ;-) We only chose to use it on this small system just so that we could get meaningful experience with it. We also had it running on another system where the next weekend we took emergency downtime and removed btrfs from it as well.

I've been using ZFS in production since it was released in Solaris 10 in 2006. It isn't perfect either. We did once hit a performance degradation which was fixed a few days later with a kernel patch. But that was 10 years ago. We never lost any data or sleep over it. We no longer have any Solaris boxes; they were all converted to Centos with ZFS. The main active ZFS pools are all 6TB of mirrored NVMe storage on systems with 2TB of ram and 48 core of INTC Platinum cpu's. Works like a charm.