"Warning: If the database resides on a Btrfs file system, you should consider disabling Copy-on-Write for the directory before creating any database."
back
wiki.archlinux.org / PostgreSQL + Btrfs
2 comments
Fun fact: I have a multi-TB, largely-write-only Postgres 9.4 database on a force-compress multi-device btrfs volume. Sadly, you must enable CoW to use transparent compression.
The performance is... not the best, and not all of that can be blamed on either my shitty choice of indexes long ago, or my decision to use firewire to attach the devices.
However, btrfs hasn't eaten any of my data, compression has given me ~2x the space to work with, and btrfs handled the sudden and unexpected loss of a device like a champ.
So what's the point of using a COW-based filesystem, and then just disabling the COW and sacrificing features that require that. Sure, you can still do snapshots (which will do COW on the modified data), but you lose compression and checksums.
The compression is not really that interesting on OLTP I guess, but losing checksums is a major PITA because it means the filesystem is no longer resilient to torn pages (at least that's my understanding). Which means you have to enable full_page_writes in PostgreSQL, which has impact on performance.
So how is BTRFS+nodatacow better than EXT4+LVM, for example?