Nachdem ich den Original-E-Mail-Thread und die Antwort von @ ewwhite gelesen habe , die ihn geklärt hat, denke ich, dass diese Frage eine aktualisierte Antwort benötigt, da die Antwort oben nur die Hälfte davon abdeckt.
Verwenden wir als Beispiel die Ausgabe in meinem Pool. Ich habe den Befehl verwendet zdb -U /data/zfs/zpool.cache -bDDD My_pool. Auf meinem System benötigte ich das zusätzliche -UArgument, um die ZFS-Cache-Datei für den Pool zu finden, die FreeNAS an einem anderen Ort als normal speichert. Möglicherweise müssen Sie das tun oder nicht. Versuchen Sie es im Allgemeinen zuerst zdbohne. -UWenn ein Cache-Dateifehler auftritt, suchen Sie die benötigte Datei mit find / -name "zpool.cache"o.ä.
Dies war meine eigentliche Ausgabe und ich habe es unten interpretiert:
DDT-sha256-zap-duplicate: 771295 entries, size 512 on disk, 165 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
2 648K 75.8G 68.6G 68.8G 1.39M 165G 149G 149G
4 71.2K 8.07G 6.57G 6.62G 368K 41.7G 34.1G 34.3G
8 28.1K 3.12G 2.34G 2.36G 281K 31.0G 23.1G 23.4G
16 5.07K 424M 232M 241M 110K 9.10G 5.06G 5.24G
32 1.09K 90.6M 51.8M 53.6M 45.8K 3.81G 2.21G 2.28G
64 215 17.0M 8.51M 8.91M 17.6K 1.39G 705M 739M
128 38 2.12M 776K 872K 6.02K 337M 118M 133M
256 13 420K 21.5K 52K 4.63K 125M 7.98M 18.5M
512 3 6K 3K 12K 1.79K 3.44M 1.74M 7.16M
1K 1 128K 1K 4K 1.85K 237M 1.85M 7.42M
2K 1 512 512 4K 3.38K 1.69M 1.69M 13.5M
DDT-sha256-zap-unique: 4637966 entries, size 478 on disk, 154 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 4.42M 550G 498G 500G 4.42M 550G 498G 500G
DDT histogram (aggregated over all DDTs):
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 4.42M 550G 498G 500G 4.42M 550G 498G 500G
2 648K 75.8G 68.6G 68.8G 1.39M 165G 149G 149G
4 71.2K 8.07G 6.57G 6.62G 368K 41.7G 34.1G 34.3G
8 28.1K 3.12G 2.34G 2.36G 281K 31.0G 23.1G 23.4G
16 5.07K 424M 232M 241M 110K 9.10G 5.06G 5.24G
32 1.09K 90.6M 51.8M 53.6M 45.8K 3.81G 2.21G 2.28G
64 215 17.0M 8.51M 8.91M 17.6K 1.39G 705M 739M
128 38 2.12M 776K 872K 6.02K 337M 118M 133M
256 13 420K 21.5K 52K 4.63K 125M 7.98M 18.5M
512 3 6K 3K 12K 1.79K 3.44M 1.74M 7.16M
1K 1 128K 1K 4K 1.85K 237M 1.85M 7.42M
2K 1 512 512 4K 3.38K 1.69M 1.69M 13.5M
Total 5.16M 638G 576G 578G 6.64M 803G 712G 715G
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39
Was das alles bedeutet und wie hoch die tatsächliche Größe der Dedup-Tabelle ist:
Die Ausgabe zeigt zwei Untertabellen, eine für Blöcke, in denen ein Duplikat vorhanden ist ( DDT-sha256-zap-duplicate ) und eine für Blöcke, in denen kein Duplikat vorhanden ist ( DDT-sha256-zap-unique ). Die dritte Tabelle darunter gibt eine Gesamtsumme für beide an, und darunter befindet sich eine zusammenfassende Zeile. Wenn wir uns nur die "Gesamt" -Zeilen und die Zusammenfassung ansehen, erhalten wir, was wir brauchen:
DDT-Größe für alle Blöcke, die mehrmals vorkommen ("DDT-sha256-zap-duplicate") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")
DDT-Größe für Blöcke, die eindeutig sind ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")
DDT-Gesamtstatistik für alle DDT-Einträge, doppelt + eindeutig ("DDT-Histogramm über alle DDTs aggregiert") :
allocated referenced
(= disk space actually used) (= amount of data deduped
into that space)
______ ______________________________ ______________________________
blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
Total 5.16M 638G 576G 578G 6.64M 803G 712G 715G
Zusammenfassung :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39
Lass uns ein bisschen Zahlen knacken.
Die Blockanzahl funktioniert wie folgt : Anzahl der Einträge in Bezug auf doppelte Blöcke = 771295, Anzahl der Einträge in Bezug auf eindeutige Blöcke = 4637966, Gesamteinträge in der DDT-Tabelle sollten 771295 + 4637966 = 5409261 sein. Die Anzahl der Blöcke in Millionen (binäre Millionen) das heißt!) wäre 5409261 / (1024 ^ 2) = 5,158 Millionen. In der Zusammenfassung finden wir insgesamt 5,16 Millionen Blöcke .
Der benötigte RAM funktioniert folgendermaßen: Die 771295-Einträge für doppelte Blöcke belegen jeweils 165 Bytes im RAM und die 4637966-Einträge für eindeutige Blöcke belegen jeweils 154 Bytes im RAM, sodass der gesamte für die Dedup-Tabelle derzeit benötigte RAM = 841510439 Bytes = 841510439 / (1024 ^ 2) MB = 803 MB = 0,78 GB RAM .
(Die auf der Festplatte verwendete Größe kann auf die gleiche Weise unter Verwendung der "Größe auf der Festplatte" berechnet werden. ZFS versucht offensichtlich, die Festplatten-E / A effizient zu nutzen und nutzt die Tatsache, dass der vom DDT belegte Festplattenspeicher nicht ausreicht Normalerweise ist das kein Problem. Daher sieht es so aus, als würde ZFS einfach einen kompletten 512-Byte-Sektor für jeden Eintrag zuweisen oder etwas in diese Richtung, anstatt nur 154 oder 165 Byte, um die Effizienz zu erhalten Kopien, die auf der Festplatte gespeichert sind (was ZFS normalerweise tut).
Die Gesamtmenge der gespeicherten Daten und der Vorteil der Deduktion: Aus der DDT-Gesamtstatistik ergeben sich 715 GB ("715 G") Daten, die nur 578 GB ("578 G") zugewiesenen Speicherplatz auf den Datenträgern belegen. Unser Verhältnis zur Einsparung von Dedup-Speicherplatz beträgt also (715 GB Daten) / (578 GB Speicherplatz, der nach dem Dedup-Vorgang verwendet wird) = 1,237 x. Dies wird in der Zusammenfassung angegeben ("Dedup = 1,24").