Après avoir lu le fil de discussion original et @ewwhite's Je pense que cette question nécessite une réponse actualisée, car la réponse ci-dessus ne couvre que la moitié de la question.
A titre d'exemple, utilisons la sortie sur mon pool. J'ai utilisé la commande zdb -U /data/zfs/zpool.cache -bDDD My_pool . Sur mon système, j'avais besoin du supplément -U arg pour localiser le fichier 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. En général, essayez zdb sans -U d'abord, et si vous obtenez une erreur de fichier cache, alors utilisez find / -name "zpool.cache" ou similaire pour localiser le fichier dont il a besoin.
C'était mon résultat réel et je l'ai interprété 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 cela signifie et comment calculer la taille réelle de la table de déduplication :
La sortie montre deux sous-tableaux, l'un pour les blocs où il existe un doublon ( 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 tableaux, et une ligne de résumé se trouve en dessous. En regardant uniquement les lignes "total" et le résumé, nous obtenons ce dont nous avons besoin :
Taille de la DDT pour tous les blocs qui apparaissent plus d'une fois ("DDT-sha256-zap-duplicate") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")
Taille du DDT pour les blocs qui sont uniques ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")
Statistiques totales de la DDT pour toutes les entrées de la DDT, duplicata + unique ("Histogramme de 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 715G
Résumé :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39
Faisons un peu de calcul.
-
Le comptage des blocs fonctionne comme suit : Le nombre d'entrées relatives aux blocs dupliqués = 771295, le nombre d'entrées relatives aux blocs uniques = 4637966, le total des entrées dans la table DDT devrait être 771295+4637966 = 5409261. Donc le nombre de blocs en millions (en millions binaires !) serait 5409261 / (1024^2) = 5,158 millions. Dans le résumé, nous trouvons qu'il y a 5,16 millions de blocs au total .
-
La RAM nécessaire fonctionne comme suit : Les 771295 entrées pour les blocs en double occupent chacune 165 octets de RAM, et les 4637966 entrées pour les blocs uniques occupent chacune 154 octets de RAM, donc le total de RAM 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 la "taille sur disque". Il est clair que ZFS essaie d'utiliser efficacement les E/S du disque et de tirer parti du fait que l'espace disque occupé par le DDT 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 de ce genre, au lieu de seulement 154 ou 165 octets, pour rester efficace. Il se peut que cela ne tienne pas compte des copies multiples conservées sur le disque, ce que ZFS fait habituellement).
-
La quantité totale de données stockées, et l'avantage de les déduire : D'après les statistiques totales de DDT, 715 Gbytes ("715G") de données sont stockées en utilisant seulement 578 GBytes ("578G") 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, ce qui est ce que le résumé nous dit ("dedup = 1.24").
