Lösung 1:
Sie können den zpool status -D poolname verwenden Befehl.
Die Ausgabe würde etwa so aussehen:
[email protected]:/volumes# zpool status -D vol1
pool: vol1
state: ONLINE
scan: scrub repaired 0 in 4h38m with 0 errors on Sun Mar 24 13:16:12 2013
DDT entries 2459286, size 481 on disk, 392 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 2.23M 35.6G 19.0G 19.0G 2.23M 35.6G 19.0G 19.0G
2 112K 1.75G 1005M 1005M 240K 3.75G 2.09G 2.09G
4 8.03K 129M 73.8M 73.8M 35.4K 566M 324M 324M
8 434 6.78M 3.16M 3.16M 4.61K 73.8M 35.4M 35.4M
16 119 1.86M 811K 811K 2.33K 37.3M 15.3M 15.3M
32 24 384K 34.5K 34.5K 1.13K 18.1M 1.51M 1.51M
64 19 304K 19K 19K 1.63K 26.1M 1.63M 1.63M
128 7 112K 7K 7K 1.26K 20.1M 1.26M 1.26M
256 3 48K 3K 3K 1012 15.8M 1012K 1012K
512 3 48K 3K 3K 2.01K 32.1M 2.01M 2.01M
1K 2 32K 2K 2K 2.61K 41.7M 2.61M 2.61M
2K 1 16K 1K 1K 2.31K 36.9M 2.31M 2.31M
Total 2.35M 37.5G 20.1G 20.1G 2.51M 40.2G 21.5G 21.5G
Die wichtigen Felder sind die Gesamtsumme zugewiesene Blöcke und die Gesamt referenzierte Blöcke. Im obigen Beispiel habe ich eine niedrige Deduplizierungsrate. 40,2 GB werden auf der Festplatte in 37,5 GB Speicherplatz gespeichert. Oder 2,51 Millionen Blöcke in einer Fläche von 2,35 Millionen Blöcken.
Um die tatsächliche Größe der Tabelle zu erhalten, siehe:
DDT-Einträge 2459286, Größe 481 auf Festplatte, 392 im Kern
2459286*392=964040112 Byte Teilen Sie durch 1024 und 1024, um zu erhalten:919,3 MB RAM .
Lösung 2:
Nach dem Lesen des ursprünglichen E-Mail-Threads und @ewwhites Antwort, die es verdeutlicht hat, denke ich, dass diese Frage eine aktualisierte Antwort benötigt, da die obige Antwort nur die Hälfte davon abdeckt.
Als Beispiel verwenden wir die Ausgabe in meinem Pool. Ich habe den Befehl zdb -U /data/zfs/zpool.cache -bDDD My_pool verwendet . Auf meinem System brauchte ich den zusätzlichen -U arg, um die ZFS-Cache-Datei für den Pool zu finden, die FreeNAS an einem anderen Ort als normal speichert; Sie können oder müssen das nicht tun. Versuchen Sie im Allgemeinen zdb ohne -U zuerst, und wenn Sie einen Cache-Dateifehler erhalten, verwenden Sie find / -name "zpool.cache" oder ähnliches, um die benötigte Datei zu finden.
Dies war meine eigentliche Ausgabe und ich habe sie 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 Ermitteln der tatsächlichen Größe der Deduplizierungstabelle:
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 existiert (DDT-sha256-zap-unique )/. Die dritte Tabelle darunter gibt eine Gesamtsumme für beide an, und darunter befindet sich eine Zusammenfassungszeile. Wenn wir uns nur die "gesamten" Zeilen und die Zusammenfassung ansehen, erhalten wir, was wir brauchen:
DDT-Größe für alle Blöcke, die mehr als einmal vorkommen ("DDT-sha256-zap-duplicate") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")
DDT-Größe für eindeutige Blöcke ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")
Gesamt-DDT-Statistiken für alle DDT-Einträge, doppelt + eindeutig ("DDT-Histogramm aggregiert über alle DDTs") :
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
Lassen Sie uns einige Zahlen knirschen.
-
Die Blockzählung funktioniert so: Anzahl der Einträge im Zusammenhang mit doppelten Blöcken =771295, Anzahl der Einträge im Zusammenhang mit eindeutigen Blöcken =4637966, Gesamteinträge in der DDT-Tabelle sollten 771295 + 4637966 =5409261 sein. Die Anzahl der Blöcke in Millionen (das sind binäre Millionen!) wäre also 5409261 / (1024^2) =5,158 Millionen. In der Zusammenfassung finden wir insgesamt 5,16 Millionen Blöcke .
-
RAM benötigt funktioniert so: 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 RAM, der jetzt für die Deduplizierungstabelle benötigt wird, =841510439 Bytes =841510439 / (1024 ^ 2) MBytes beträgt =803 MB =0,78 GB RAM .
(Die verwendete Größe auf der Festplatte kann auf die gleiche Weise ermittelt werden, indem die Zahlen zur „Größe auf der Festplatte“ verwendet werden. ZFS versucht eindeutig, die Festplatten-E/A effizient zu nutzen und die Tatsache zu nutzen, dass der vom DDT belegte Speicherplatz nicht vorhanden ist "normalerweise kein Problem. Es sieht also so aus, als ob ZFS einfach einen vollständigen 512-Byte-Sektor für jeden Eintrag oder etwas in dieser Richtung zuweist, anstatt nur 154 oder 165 Bytes, um es effizient zu halten. Dies beinhaltet möglicherweise keine Erlaubnis für mehrere Kopien, die auf der Festplatte gespeichert werden, was ZFS normalerweise tut.) -
Die Gesamtmenge der gespeicherten Daten und der Nutzen aus der Deduplizierung: Aus der gesamten DDT-Statistik werden 715 GByte ("715 G") an Daten gespeichert, wobei nur 578 GByte ("578 G") zugewiesener Speicher auf den Festplatten verwendet werden. Unser Speicherplatzeinsparungsverhältnis für Deduplizierungen beträgt also (715 GB Daten) / (578 GB belegter Speicherplatz nach der Deduplizierung) =1,237 x, was uns die Zusammenfassung sagt ("dedup =1,24").