4 ms·
Doesn't btrfs suffer crippling performance penalties for DBs unless you disable its marquee features of copy-on-write and checksumming?
by curt15 3y ago
Doesn't btrfs suffer crippling performance penalties for DBs unless you disable its marquee features of copy-on-write and checksumming?
- vlovich123 3y agoDon’t XFS and ext4 also support CoW?
- klysm 3y agoIf ext4 does, I’m not aware of it. The only widely (up for debate) used file systems I know of that offer snapshotting are btrfs and zfs
- ptman 3y agoreflink probably, but not filesystem snapshots, or do they?
- vlovich123 3y agoAh, I was thinking specifically about ref link rather than full disk snapshots.
- ComputerGuru 3y agoI don’t know about btrfs, but zfs (correctly tuned) is also famously CoW and simultaneously a good option for many Postgres deployments.
- smilliken 3y agoPostgreSQL + ZFS is controversial. My experience was that it was inefficient on space and CPU, and especially memory. It would hang for 10+ minutes at a time one every day or two (doing a single threaded sweep across all RAM). And sometimes it would totally hang the system, requiring a reboot. I would describe the experience as hellish. Some of these symptoms only appear when the database has high load, so basic testing on a staging system doesn't tell you about stability on a production system. PostgreSQL + ext4 is uneventful, lower latency, and less wasteful of resources.
- ComputerGuru 3y agoCurious. What OS? We’ve been running it in production on FreeBSD/ZFS for probably five years or so without issue, but not running at near system capacity.
- nalexpear 3y agoFor this project, I used btrfs because it was quick to use as a proof-of-concept and I happened to be most familiar with it of the CoW-capable file systems. But pg_branch is easy to extend with other snapshot-capable fs (it's a single trait, internally, that someone would need to implement). Happy to accept pull requests for supporting e.g. ZFS or XFS.