Beeinflusst zfs encryption die size?

[h^2]

Ich habe hier ein dataset im Pool, einmal unverschlüsselt und dann einmacl send | receive -x encryption:

zocean/data/jails/wg                         2.86G  5.42T  2.86G  /data/jails/wg
zocean/data/jails/wg2                        3.56G  5.42T  3.33G  /data/jails/wg2

zocean/data/jails/wg                         compressratio  2.28x  -
zocean/data/jails/wg2                        compressratio  2.15x  -

Ist das normal? Und warum? Ich dachte, das macht erst Kompression und dann Verschlüsselung? Dann sollte es doch keinen Unterschied machen.

 

[Rosendoktor]

Hast Du auch den gleichen Kompressionsalgorithmus in beiden Datasets verwendet?

 

[medV2]

Ohne jetzt die Implementierungsdetails zu kennen: Die beiden möglichen Varianten bei ZFS sind aes-ccm und aes-gcm. Beides sind authentifizierte Chipher, es werden also zusätzliche Informationen (HMAC/TAG) gespeichert. Dazu könnte das Padding noch eine Rolle spielen.

 

[mr44er]

Wie groß ist die recordsize auf beiden datasets? zstd(-3) wurde irgendwann der neue standard vs. lz4

 

[h^2]

Hast Du auch den gleichen Kompressionsalgorithmus in beiden Datasets verwendet?

compression ist bei beiden "=on", und ich habe beim send auch nicht -x compression angegeben, insofern sollte er nicht neukomprimieren. In jedem Fall ist der unverschlüsselte auch per recv reingekommen, insofern sind sie wenn dann beide neukomprimiert wurden.

Ohne jetzt die Implementierungsdetails zu kennen: Die beiden möglichen Varianten bei ZFS sind aes-ccm und aes-gcm. Beides sind authentifizierte Chipher, es werden also zusätzliche Informationen (HMAC/TAG) gespeichert. Dazu könnte das Padding noch eine Rolle spielen.

Ich habe testweise mal aes-128-gcm verwendet. Ein bisschen overhead fände ich OK, so im 1-2% Bereich. Aber hier geht's um sehr viel mehr.

Wie groß ist die recordsize auf beiden datasets? zstd(-3) wurde irgendwann der neue standard vs. lz4

Bei beiden 128K. Wie gesagt, ich habe ein volles send/recv gemacht und nur -x encryption gesetzt, d.h. alle andere properties sollten identisch sein.

 

[medV2]

Wie gesagt in die Implementierung in ZFS hab ich keine Ahnung, aber: AES-GCM-128 braucht pro Record zusäztlich 128Bit. Jetzt könnte man annehmen das sei ein Block in ZFS. Die Recordsize in ZFS ist jetzt aber nur die maximale Blocksize, sprich wenn du viele kleine Datein hast, wären das viele Blöck mit je 128Bit zusätzlich. Es könnte auch sein, dass hier mehrere AES-GCM Records pro Block gemacht werden, da kann ich mich zu wenig aus. Aber ja, da ist dein Verlust grob geschätzt deutlich zu viel - es sei denn du hast hier nur Sourcecode mit Datein <4k rumliegen.
Was passiert wenn du ohne encryption send/recv machst? Womöglich wird irgend etwas Dedupliziertes wieder de-dedupliziert? Von BTRFS kenne ich das Problem..