[zaarn]

SQLite on ZFS needs the Fsync behaviour to be off, otherwise SQLite will randomly hang the application as the fsync will wait for the txg to commit. This can take a minute or two, in my experience.

Btrfs is a better choice for SQLite.

[supriyo-biswas]

Btw this concern also applies to other databases, although probably it manifests in the worst way in SQLite. Essentially, you’re doing a WAL over the file systems’ own WAL-like recovery mechanism.

[zaarn]

I've not observed other databases locking up on ZFS, Postgres and MySQL both function just fine, without needing to modify any settings.

[throw0101b]

> SQLite on ZFS needs the Fsync behaviour to be off […]

    zfs set sync=disabled mydata/mydb001

* https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops...

[zaarn]

As noted in a sibling comment, this causes corruption on power failure.

[fread2281]

This is a bug in zfs or in sqlite, sync=disabled should never cause actual corruption (it should at worst make existing corruption bugs in sqlite more likely & cause loss of committed sqlite transactions)

[zaarn]

I highly doubt it's an SQLite bug, considering how thoroughly they test their code to behave correctly as long as their assumptions are filled. And those assumptions are clearly violated when SQLite runs on ZFS with sync=disabled (since writes may not be written to disk despite fsync).

[fread2281]

(see https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSTXGsAndZ... for an explanation of sync=disabled)