1. 6
  1.  

  2. 3

    Running a database on ZFS always feels a bit weird to me. ZFS’s second-lowest-level abstraction is a transactional object layer, which guarantees that groups of updates to objects either persist or don’t persist, atomically. The lowest level of PostgreSQL is doing exactly the same thing. In between the two, sits the ZFS POSIX Layer, which exposes POSIX filesystem abstractions on top of the atomic transactional model. When you run PostgreSQL on top of ZFS you have two things providing atomic transactions on disk, with the ZPL sandwiched between them.

    The ZPL isn’t the only top layer in ZFS. There’s also the zvol layer, which exposes a block device abstraction. I’d love to see a third one added that exposed the functionality of the transactional object abstractions and delegated naming to the userspace component, for use by databases (and anything else that wanted a transactional data store, rather than a filesystem).

    1. 2

      They claim they can adjust the transactional nature of full page writes because of ZFS. I’m not totally sure if they’re correct, but they are trying not to pay it twice…

      Higher durability - This allows us to disable full_page_writes in Postgres, since torn pages are not possible after a crash. This improves write performance and decreases overall IO.