Re: I can't stand misleading charts
great performance and compression ratio.
I use ZFS's compression feature a LOT on FreeBSD workstations and servers. It's ok for binaries, really good for text (like source and e-mail repositories). Additionally for source and e-mail storage on the server I use automatic data replication (basically 2 copies of the stored data). With compression, the replication isn't that much of a 'hit'.
on a fairly large project's source tree (which had some compiler output files in it) "du -A" (actual reported size, not on-disk size) showed a total file size of 1.9G, but without the '-A' (actual on-disk size) it showed 593M. That's using the native ZFS compression. Overall in the 'catch all' source tree, with lots of already-compressed tarballs, svn and github metadata, and other binary files, there was a size reduction of about 25% (14G vs 19G). So YMMV on that one. [but I nearly always use compression anyway, especially for archived files and text].
I'm pretty sure that compression works poorly for downloaded cat videos and compressed audio, so as would be expected I turn it off on those directory trees. It's just a setting. (you create it as a separate zpool that's part of the main zroot, basically, and set up compression/replication etc. for that particular pool. easy enough, but a little planning helps).
Back in the winders 'stacker' days (and when NTFS finally got compression) I confirmed that compressed data often read faster than uncompressed due to drive speeds, so it made sense to just compress the entire drive by default. I don't know if that's still the case with spinny drives (i.e. compressed data reads faster), but it may be a performance hit for SSDs. Still it seems to be fast enough as far as I'm concerned, using large spinny drives.