[_joel]

I'm sure it's a lot better now but everytime I see btrfs I get PTSD.

[060880]

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.

[__turbobrew__]

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

[NelsonMinar]

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.

[stackskipton]

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

[uroni]

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.

[poly2it]

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

[metadat]

Years of serious corruption bugs.

[dundercoder]

Gluster was that for me

[sigio]

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

[dundercoder]

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)

[_joel]

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