ZFS isn’t viable for SQLite unless you turn off fsync’s in ZFS, because otherwise you will have the same experience I had for years; SQLite may randomly hang for up to a few minutes with no visible cause, if there isn’t sufficient write txg’s to fill up in the background. If your app depends on SQLite, it’ll randomly die.Btrfs is a better choice for sqlite, haven’t seen that issue there.
Modified3019|7 months ago
The latest comment seems to be a nice summary of the root cause, with earlier in the thread pointing to ftruncate instead of fsync being a trigger:
>amotin
>I see. So ZFS tries to drop some data from pagecache, but there seems to be some dirty pages, which are held by ZFS till them either written into ZIL, or to disk at the end of TXG. And if those dirty page writes were asynchronous, it seems there is nothing that would nudge ZFS to actually do something about it earlier than zfs_txg_timeout. Somewhat similar problem was recently spotted on FreeBSD after #17445, which is why newer version of the code in #17533 does not keep references on asynchronously written pages.
Might be worth testing zfs_txg_timeout=1 or 0
throw0101b|7 months ago
Which you can do on a per dataset ('directory') basis very easily:
* https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops...Meanwhile all the rest of your pools / datasets can keep the default POSIX behaviour.
ezekiel68|7 months ago
zaarn|7 months ago
You cannot have SQLite keep your data and run well on ZFS unless you make a zvol and format it as btrfs or ext4 so they solve the problem for you.
kentonv|7 months ago
jclulow|7 months ago
What you're describing sounds like a bug specific to whichever OS you're using that has a port of ZFS.
zaarn|7 months ago
I've encountered this bug both on illumos, specifically OpenIndiana, and Linux (Arch Linux).
unknown|7 months ago
[deleted]