Unless I'm just parroting truisms here, dedupe is almost never a good idea and compression is a much more common case-by-case.
> So personally I'd encourage messing around (on something non-prod, of course). Measure measure measure! Does it actually make any difference.
100%. So much depends on the particular workload and resources.
> And making backups, even for ZFS backed filesystems. Sacrilege, I know.
Logical backups, specifically. We have seen more than once corruption and data-loss in replicated encrypted snapshots due to bugs in ZFS.
It is cheaper to buy more disk than the memory to enable dedup (somebody could run the numbers). ZFS ARC also likes lots of memory and you get good performance gains with more memory allocated to it.
In other words, turn on LZ4 compression everywhere and don’t think about it otherwise.
Dedupe can be used to infer secret data. .. more news at 11
My personal approach to filesystem evaluation is pretty much "How long has it been since I've seen someone talk about a data loss bug". This is my first time hearing one for ZFS. BTRFS seems to have at least one post a year. Ext4 has almost none, but maybe that's because people trust it and blame hardware when unsure what the issue is.
Mind, you shouldn't really change the record size without knowing your use-case. Make a PostgreSQL file system, set it's recordsize to 8k. That's a good idea.
Not so much a good idea doing that to all your filesystems. Stick to the defaults without a good justification to deviate.
https://openzfs.github.io/openzfs-docs/Performance%20and%20T...
compression=lz4 recordsize=32K
In postgres -> full_page_writes=off
This [0] is a brief post on MySQL, but most of it applies equally to Postgres.
[0]: https://www.percona.com/blog/mysql-zfs-performance-update/
atime is the most useless filesystem feature I’ve heard of. But on most Unix-like systems it’s enabled by default and the main thing it does is turn reads into writes, degrading performance. All the while ctime isn’t a standard Unix filesystem feature. And ctime to me always seemed infinitely more useful (and cheaper!) than atime.
</rant>
Finding old objects in a cache is an issue specific to caches and should be implemented there.
Here, have at it: https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops...
So personally I'd encourage messing around (on something non-prod, of course). Measure measure measure! Does it actually make any difference.
It's a shame a bug crept in to an otherwise pretty much faultless filesystem. I'm sure there are some truths in there about commercial support or not running the bleeding edge or whatever. And making backups, even for ZFS backed filesystems. Sacrilege, I know.