In welcher Reihenfolge werden Daten in ein ZFS-Dateisystem unter ZFS unter Linux geschrieben?
Das einzige konkrete Dokument, das ich fand,http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.htmlsagt;When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.
Wenn dies jedoch der Fall wäre, würde Dedup keine Blöcke deduplizieren, die mit unterschiedlichen Komprimierungsalgorithmen komprimiert wurden.
Ich habe MySQLF getestet und glaube, dass die Reihenfolge die folgende ist: dedup, compress, encrypt.
Mein Test-Setting:
zpool create tank /dev/sdb
zfs create tank/lz4
zfs create tank/gzip9
zfs set compression=lz4 tank/lz4
zfs set compression=gzip-9 tank/gzip9
zfs set dedup=on tank
Ausgabe vonzfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 106K 19,3G 19K /tank
tank/gzip9 19K 19,3G 19K /tank/gzip9
tank/lz4 19K 19,3G 19K /tank/lz4
Erzeugen Sie eine zufällige Datei mitdd if=/dev/urandom of=random.txt count=128K bs=1024
131072+0 Datensätze ein
131072+0 Datensätze aus
134217728 Bytes (134 MB) kopiert, 12,8786 s, 10,4 MB/s
Ausgabe der Zpool-Liste im leeren Pool:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 19,9G 134K 19,9G - 0% 0% 1.00x ONLINE -
Kopieren Sie die Dateien anschließend mit unterschiedlichen Komprimierungsalgorithmen in die Datensätze:
cp random.txt /tank/lz4
cp random.txt /tank/gzip9
Ausgabe zfs listnach dem Kopieren:
NAME USED AVAIL REFER MOUNTPOINT
tank 257M 19,1G 19K /tank
tank/gzip9 128M 19,1G 128M /tank/gzip9
tank/lz4 128M 19,1G 128M /tank/lz4
Ausgabe nach zpool listdem Kopieren:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 19,9G 129M 19,7G - 0% 0% 2.00x ONLINE -
Das Deduplizierungsverhältnis beträgt2.0nach dem Kopieren derselben Datei in verschiedene Datensätze. Meiner Meinung nach bedeutet dies, dass die Deduplizierung aufDaten-Blöcke vor der Komprimierung und Verschlüsselung.
Kann bitte jemand bestätigen, ob das stimmt?
Antwort1
Es stellt sich heraus, dasshttp://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.htmlist richtig.
Beim Schreiben einer Datei werden die Daten komprimiert, verschlüsselt und die Prüfsumme überprüft. Anschließend werden die Daten, sofern möglich, dedupliziert.
Meine Annahme mit der zufälligen Datei war falsch. Es scheint, dass ZFS die Komprimierung abbricht, wenn es eine bestimmte Mindestkomprimierungsrate nicht erreichen kann.
Zitat aushttps://wiki.illumos.org/display/illumos/LZ4+Compression
Besonders hervorzuheben ist auch die sehr hohe Leistung von LZ4 bei inkomprimierbaren Daten. Dies wird durch die Integration eines „Early Abort“-Mechanismus erreicht, der ausgelöst wird, wenn LZ4 die erwartete Mindestkomprimierungsrate (12,5 % bei ZFS) nicht erreichen kann.
Zum Testen habe ich mit eine Textdatei aus meinem Dateisystem erstellt find / >> tree.txt.
Nach dem Kopieren der Datei in beide Datensätze zpool get dedupratioerfolgte die Rückgabe:
NAME PROPERTY VALUE SOURCE
tank dedupratio 1.00x -
Deduplizierung ist eigentlich der letzte Teil dieser Schreibkette. Die Wahl anderer Komprimierungsalgorithmen führt zu einer schlechten Deduplizierungsrate!
Leider unterstützt meine ZoL-Version keine Verschlüsselung. Es scheint jedoch, dass die Verschlüsselung verschiedener Datensätze auch die Deduplizierung beeinträchtigen könnte. Informationen zur Verschlüsselung:https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html