Po przeczytaniu oryginalnego wątku e-mail i odpowiedzi @ ewwhite, która go wyjaśniła, myślę, że to pytanie wymaga zaktualizowanej odpowiedzi, ponieważ powyższa odpowiedź obejmuje tylko połowę.
Jako przykład użyjmy danych wyjściowych z mojej puli. Użyłem polecenia zdb -U /data/zfs/zpool.cache -bDDD My_pool. W moim systemie potrzebowałem dodatkowego -Uargumentu, aby zlokalizować plik pamięci podręcznej ZFS dla puli, który FreeNAS przechowuje w innej lokalizacji niż normalna; być może będziesz musiał to zrobić lub nie. Z reguły spróbuj najpierw zdbbez -U, a jeśli wystąpi błąd pliku pamięci podręcznej, użyj find / -name "zpool.cache"lub podobnie, aby zlokalizować potrzebny plik.
To był mój faktyczny wynik i zinterpretowałem go poniżej:
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
Co to wszystko oznacza i ustalenie rzeczywistego rozmiaru tabeli deduplikacji:
Dane wyjściowe pokazują dwie podtabele , jedną dla bloków, w których istnieje duplikat ( DDT-sha256-zap-duplicate ), a drugą dla bloków, w których duplikat nie istnieje ( DDT-sha256-zap-unique ) /. Trzecia tabela poniżej zawiera ogólną sumę dla obu tych elementów, a poniżej znajduje się wiersz podsumowania. Patrząc tylko na „sumaryczne” wiersze i podsumowanie, daje nam to, czego potrzebujemy:
Rozmiar DDT dla wszystkich bloków, które pojawiają się więcej niż jeden raz („DDT-sha256-zap-duplicate”) :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")
Rozmiar DDT dla bloków, które są unikalne („DDT-sha256-zap-unique”) :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")
Łączne statystyki DDT dla wszystkich wpisów DDT, powielone + niepowtarzalne („Histogram DDT zagregowany dla wszystkich 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
Podsumowanie :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39
Zróbmy trochę chrupania liczb.
Liczba bloków działa w następujący sposób: Liczba wpisów związanych z duplikatami bloków = 771295, liczba wpisów związanych z unikalnymi blokami = 4637966, całkowita liczba wpisów w tabeli DDT powinna wynosić 771295 + 4637966 = 5409261. Tak więc liczba bloków w milionach (milionach binarnych to znaczy!) wyniesie 5409261 / (1024 ^ 2) = 5,158 miliona. Podsumowując, stwierdzamy, że w sumie jest 5,16 mln bloków .
Potrzebna pamięć RAM działa w następujący sposób: każdy z 771295 wpisów dla duplikatów bloków zajmuje 165 bajtów w pamięci RAM, a każdy 4646966 wpisów dla unikalnych bloków zajmuje 154 bajty w pamięci RAM, więc całkowita pamięć RAM potrzebna teraz dla tabeli deduplikacji = 841510439 bajtów = 841510439 / (1024 ^ 2) MBytes = 803 MB = 0,78 GB pamięci RAM .
(Użyty rozmiar dysku można obliczyć w ten sam sposób, używając liczb „rozmiar na dysku”. Najwyraźniej ZFS stara się efektywnie wykorzystywać dyskowe operacje we / wy i wykorzystując fakt, że miejsce na dysku zajmowane przez DDT nie jest to zwykle problem. Wygląda więc na to, że ZFS po prostu przydziela pełny 512-bajtowy sektor dla każdego wpisu lub coś w tym stylu, zamiast tylko 154 lub 165 bajtów, aby utrzymać jego wydajność. Może to nie obejmować żadnego limitu dla wielu kopie przechowywane na dysku, co zwykle robi ZFS.)
Całkowita ilość przechowywanych danych i korzyści z ich dedukcji: Ze statystyk DDT ogółem 715 GB („715 G”) danych jest przechowywanych przy użyciu zaledwie 578 GB („578 G”) przydzielonego miejsca na dyskach. Tak więc nasz współczynnik oszczędności miejsca deduplikacji wynosi (715 GB danych) / (578 GB miejsca wykorzystanego po deduplikacji) = 1,237 x, co mówi nam podsumowanie („dedup = 1,24”).