Sadly they didn’t try DragonFly BSD. Those people have done quite a bit of work in that area and the last benchmark on their website is over 5 years old.
Agreed. I’m (just a nobody/user) hopeful that in a few more releases, presumably after HAMMER2 gets more dev time, the benchmarks will be re-done.
Anyone have ideas why FreeBSD did so poorly on the read intensive portion of the test?
I’m wondering if the zfs ARC was fighting over memory with PostgreSQL. Maybe some additional ARC memory limit tuning (eg. vfs.zfs.arc_max) would have helped? Maybe additionally setting primarycache=metadata too.
The fact that its ZFS filesystem was configured with lz4 compression while none of the others had any compression at all might have something to do with it. Decompression is done per-block, and each block was configured to be 8K bytes, and the more concurrent requests are made to the filesystem, the higher the chances are that different blocks might be requested, the more data the filesystem actually has to decompress before actually having a reply, even after fetching.