ZFS crypto VS geli

h^2

hat ne Keule +1
Ich war eigentlich fest überzeugt für den Fileserver jetzt auf ZFS crypto zu setzen, habe aber jetzt öfter gelesen, dass es sich sehr deutlich auf die Read-Performance auswirken soll:


Habt ihr persönliche Erfahrungen damit? Wisst ihr inbesondere ob unter FreeBSD für die Verschlüsselung AVX2 genutzt wird? Das scheint einen riesigen Unterschied zu machen.
Mein Desktop behauptet zumindest, dass er es für die Prüfsummen nutzt:
Code:
% sysctl -a | grep avx
vfs.zfs.fletcher_4_impl: [fastest] scalar superscalar superscalar4 sse2 ssse3 avx2  
vfs.zfs.sha512_impl: cycle [fastest] generic x64 avx avx2  
vfs.zfs.sha256_impl: cycle [fastest] generic x64 ssse3 avx avx2 shani  
vfs.zfs.blake3_impl: cycle [fastest] generic sse2 sse41 avx2


Bin mit geli soweit immer zufrieden gewesen, aber erhoffe mir von der nativen Encryption:
  • modularer (ich kann später entscheiden bestimmte datesets anders zu verschschlüsseln),
  • einfacher (brauche nur einen Pool)
  • zukunftssicherer (kann innerhalb des Pools in der Zukunft auf andere Algorithmen wechseln)
  • offsite Backups wo der Zielserver nie die Schlüssel sieht

Das Geheimhalten der dataset-list ist mir persönlich nicht wichtig.
 
So, hier ein erster Vergleich vierer identischer NVMEs (siehe hier für Erklärung der Spalten):

Code:
| Disk                       | IOPS rand-read | IOPS read  | IOPS write | MB/s read | MB/s write | "cat speed" MB/s |
|----------------------------|---------------:|-----------:|-----------:|----------:|-----------:|-----------------:|
| nda0                       |          54700 |    809000  |     453000 |      4796 |       5868 |             2732 |
| nda1+geli-aes-256-xts      |          40000 |    793000  |     446000 |      3332 |       3334 |              952 |
| nda2+zfs-enc-aes-256-gcm   |          26100 |    513000  |     285000 |      3871 |       4648 |             2638 |
| nda3+zfs-enc-aes-128-gcm   |          29300 |    532000  |     353000 |      3971 |       4794 |             2631 |

=> ZFS encryption resultiert in weniger IOPS aber besserem seq-read und seq-write Durchsatz, vor allem im manuellen Lesen per cat.

Das scheint ja erst einmal die Befürchtungen zu widerlegen :)

Geli habe ich so eingerichtet: geli init -b -s4096 -l256 und es läuft mit accelerated software.
 
Zurück
Oben