bzip/gzip war auch nie wirklich auf hohen Durchsatz optimiert bzw stammt auch einfach noch aus einer anderen Zeit (single-threaded; wenig/keine HW-beschleunigungen etc...). Zwar wurde hier viel getan, trotzdem kommt es lange nicht an die hohen Durchsatzraten moderner Kompressionsverfahren ran.
Direkter "Konkurrent" zu zstd bzw Referenz für Vergleiche sollte LZ4 sein - das ist bei der Kompression (v.a. in relevanten CRs) noch deutlich performanter, dafür skaliert zstd aber sehr gut bei der dekompression, speziell bei steigender Anzahl threads und sehr hohen CR (die aber in der praxis extrem selten ins gewicht fallen):
http://blosc.org/posts/codecs-pgo/
Für dateisysteme/datasets mit primär lesenden Zugriffen lohnt sich zstd also ggf. Bei höherer Gewichtung auf schreibende Zugriffe kann LZ4 noch immer die bessere Wahl sein, speziell da es dynamisch blöcke überspringen kann wenn diese sich nicht komprimieren lassen; das kann den Durchsatz _enorm_ erhöhen (und führt auch zu den oft beobachteten Fluktuationen im Durchsatz). Wirklichen Aufschluss welches verfahren "besser" für den eigenen Anwendugsfall ist, kann nur ein eigener Benchmark mit der später Anliegeneden Arbeitslast geben.
*zip glänzt eher wenn es um maximale Kompressionsraten geht und der Durchsatz im Hintergrund steht - für reine Datengräber oder kalten Storage kann das durchaus sinnvoll sein. Für datasets mit text-/logfiles die relativ langsam wachsen und lange mit wenig Lesezugriffen liegen bleiben ist *zip ebenfalls gut geeignet.
und das beste ist, dass der Algorithmus in btrfs bereits zur transparenten Verschlüsselung zur Verfügung steht (in buster und unstable).
btrfs vermarktet Kompression als Verschlüsselung??