Solution 1 :
Vous pouvez utiliser le zpool status -D poolname commande.
La sortie ressemblerait à :
[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
Les champs importants sont le Total blocs alloués et le Total blocs référencés. Dans l'exemple ci-dessus, j'ai un faible taux de déduplication. 40.2G sont stockés sur disque dans 37.5G d'espace. Ou 2,51 millions de blocs dans un espace de 2,35 millions de blocs.
Pour obtenir la taille réelle du tableau, voir :
Entrée DDT 2459286, taille 481 sur disque, 392 dans le cœur
2459286*392=964040112 octets Divisez par 1024 et 1024 pour obtenir :919,3 Mo de RAM .
Solution 2 :
Après avoir lu le fil de discussion d'origine et @ewwhite réponse qui l'a clarifiée, je pense que cette question nécessite une réponse mise à jour, car la réponse ci-dessus n'en couvre que la moitié.
À titre d'exemple, utilisons la sortie sur ma piscine. J'ai utilisé la commande zdb -U /data/zfs/zpool.cache -bDDD My_pool . Sur mon système, j'avais besoin des -U supplémentaires arg pour localiser le fichier de cache ZFS pour le pool, que FreeNAS stocke dans un emplacement différent de la normale ; vous pouvez ou non avoir besoin de le faire. Essayez généralement zdb sans -U d'abord, et si vous obtenez une erreur de fichier cache, utilisez alors find / -name "zpool.cache" ou similaire pour localiser le fichier dont il a besoin.
C'était ma sortie réelle et je l'ai interprétée ci-dessous :
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
Ce que tout cela signifie et calcul de la taille réelle de la table de déduplication :
La sortie montre deux sous-tables, une pour les blocs où un doublon existe (DDT-sha256-zap-duplicate ) et un pour les blocs où aucun doublon n'existe (DDT-sha256-zap-unique )/. Le troisième tableau en dessous donne un total global pour les deux, et il y a une ligne récapitulative en dessous. En regardant uniquement les lignes "totales" et le résumé, nous avons ce dont nous avons besoin :
Taille DDT pour tous les blocs qui apparaissent plus d'une fois ("DDT-sha256-zap-dupliquer") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")Taille DDT pour les blocs qui sont uniques ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")Statistiques DDT totales pour toutes les entrées DDT, doublons + uniques ("Histogramme DDT agrégé sur tous les DDT") :
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 715GRésumé :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39
Faisons quelques calculs.
-
Le nombre de blocs fonctionne comme ceci : Nombre d'entrées liées aux blocs en double =771295, nombre d'entrées liées aux blocs uniques =4637966, le nombre total d'entrées dans la table DDT devrait être de 771295 + 4637966 =5409261. Ainsi, le nombre de blocs en millions (en millions binaires, c'est-à-dire !) serait 5409261 / (1024^2) =5,158 millions. Dans le résumé, nous constatons qu'il y a 5,16 millions de blocs au total .
-
La RAM nécessaire fonctionne comme ceci : Les 771295 entrées pour les blocs en double occupent chacune 165 octets en RAM, et les 4637966 entrées pour les blocs uniques occupent chacune 154 octets en RAM, donc la RAM totale nécessaire pour la table de déduplication en ce moment =841510439 octets =841510439 / (1024 ^ 2) Mo =803 Mo =0,78 Go de RAM .
(La taille sur disque utilisée peut être calculée de la même manière, en utilisant les chiffres de "taille sur disque". Ce n'est normalement pas un problème.Il semble donc que ZFS alloue simplement un secteur complet de 512 octets pour chaque entrée, ou quelque chose du genre, au lieu de seulement 154 ou 165 octets, pour le garder efficace.Cela peut ne pas inclure d'allocation pour plusieurs copies conservées sur disque, ce que ZFS fait généralement.) -
La quantité totale de données stockées et l'avantage de la déduplication : D'après les statistiques DDT totales, 715 Go (« 715 Go ») de données sont stockées en utilisant seulement 578 Go (« 578 Go ») de stockage alloué sur les disques. Ainsi, notre ratio d'économie d'espace de déduplication est de (715 Go de données) / (578 Go d'espace utilisé après la déduplication) =1.237 x, c'est ce que nous dit le résumé ("dedup =1.24").