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.

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 hit a panic in btrfs using an ubuntu 24 LTS kernel. The trauma is still well and alive.

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.

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.

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