zfs bei Linux-Komprimierung und Dedup-Reihenfolge

2225
Martin Seitl

In welcher Reihenfolge werden Daten in ein zfs-Dateisystem unter zfs unter Linux geschrieben?

Das einzige spezifische Dokument, das ich unter http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html gefunden habe, sagt: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 zutrifft, würde dedup keine Blöcke mit verschiedenen Kompressionsalgorithmen komprimieren.

Getestet habe ich mysqlf und ich glaube, dass die Reihenfolge ist die folgende: 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 von zfs 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 mit dd 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 in einem 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 dann die Dateien mit unterschiedlichen Kompressionsalgos 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 des zpool listNachkopierens:

NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 19,9G 129M 19,7G - 0% 0% 2.00x ONLINE -

Das dedup-Verhältnis beträgt 2,0, nachdem dieselbe Datei in verschiedene Datensätze kopiert wurde. Meiner Meinung nach bedeutet dies, dass dedup auf geschieht Daten -Blöcke vor der Komprimierung und Verschlüsselung.

Könnte jemand überprüfen, ob dies richtig ist?

4

1 Antwort auf die Frage

1
Martin Seitl

It turns out, that http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html is right.

When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.

My assumption with the random file was incorrect. It seems that ZFS aborts compression if it cannot achieve a certain minimum compression ratio.

quote from https://wiki.illumos.org/display/illumos/LZ4+Compression

Another particular thing to note is that LZ4's performance on incompressible data is very high. It achieves this by incorporating an "early abort" mechanism which will trigger if LZ4 can't meet the expected minimum compression ratio (12.5% on ZFS).

For testing i created a textfile from my filesystem with find / >> tree.txt.

After copying the file to both datasets and then zpool get dedupratio did return:

NAME PROPERTY VALUE SOURCE tank dedupratio 1.00x -

Dedup is really the last part in this write chain. Choosing different compression-algorithms will result in poor dedupratio!

Unfortunately my ZoL-version does not support encryption. But it seems that encrypting different datasets could also ruin dedup. Info on encryption: https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html

Verwandte Probleme