Same here. Had a production node running btrfs under heavy write load (lots of small files, frequent creates) and spent two days debugging what turned out to be filesystem-level corruption. Switched to ext4 and never looked back. The article doesn't mention what filesystem sits under Versitygw here, which seems like a pretty relevant omission for anyone thinking of replicating the setup.

I'd worry about file create, write, then fsync performance with btrfs, but not about reliability or data-loss.

But a quick grep across versitygw tells me they don't use Sync()/fsync, so not a problem... Any data loss occurring from that is obviously not btrfs fault.

Care to elaborate? I've heard good things about it, but am personally a ZFS user.

Years of serious corruption bugs.

Gluster was that for me

Ah, another one! Yep, also same, before ceph days at least (although I've had my own, albeit self-inflicted, nightmare there too).

Yup, still get nightmares about glusterfs.... still have one customer running on it.

I heard it got better, but we ran into the BOTF (billions of tiny files) issue around 2016. (For a genealogy startup this was a serious issue)

I hit a panic in btrfs using an ubuntu 24 LTS kernel. The trauma is still well and alive.

Same, and reasoning around inodes feels easy fixed by just upping inode per KB from 16k to 4k which is likely block size anyways.

I'm a little surprised it's not ZFS. Too difficult to add to their Linux environment? That's still a problem here in 2026.