I'm sure it's a lot better now but everytime I see btrfs I get PTSD.
Same, and reasoning around inodes feels easy fixed by just upping inode per KB from 16k to 4k which is likely block size anyways.
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.
I hit a panic in btrfs using an ubuntu 24 LTS kernel. The trauma is still well and alive.
Care to elaborate? I've heard good things about it, but am personally a ZFS user.
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.