Techniki kompresji stosowane w Data Domain wykorzystują najnowocześniejsze techniki w celu zmniejszenia fizycznej przestrzeni wymaganej przez dane klienta. Technologie i pomiary poziomów kompresji są złożonymi zagadnieniami. W tym dokumencie omówiono niektóre terminologie, kompromisy i miary, aby lepiej wyjaśnić używane typy kompresji, terminologię i inne aspekty kompresji w systemie Data Domain.
DOTYCZY:
Wszystkie modele Data Domain
Ostatnia aktualizacja: Styczeń, 2024
Kompresja to technologia ograniczenia ilości danych, która ma na celu przechowywanie zestawu danych przy użyciu mniejszej ilości miejsca fizycznego. W systemach Data Domain (DDOS) wykonujemy deduplikację i kompresję lokalną w celu kompresji danych użytkownika. Deduplikacja służy do identyfikacji nadmiarowych segmentów danych i przechowywania tylko niepowtarzalnych segmentów. Kompresja lokalna dodatkowo kompresuje unikatowe segmenty danych za pomocą określonych algorytmów kompresji, takich jak lz, gzfast, gz, i tak dalej. Ogólna kompresja danych użytkownika w DDOS to połączenie deduplikacji i kompresji lokalnej. W DDOS do pomiaru skuteczności kompresji danych używany jest „współczynnik kompresji”. Ogólnie rzecz biorąc, jest to stosunek całkowitego rozmiaru danych użytkownika do całkowitego rozmiaru skompresowanych danych lub rozmiaru wykorzystanej przestrzeni fizycznej.
System plików Data Domain to system plików deduplikacji o strukturze dziennika. System plików działający na zasadzie dziennika tylko dołącza dane do systemu, a samo usunięcie nie zwalania fizycznego miejsca. Takie systemy plików wykorzystują odśmiecanie pamięci, aby odzyskać nieużywane miejsce. Cechy systemu plików o strukturze dziennika i technologii deduplikacji w połączeniu sprawiają, że trudno jest jednoznacznie zrozumieć wszystkie aspekty kompresji w DDOS.
W przypadku kompresji istnieje wiele aspektów, które możemy zmierzyć. W tym dokumencie omówimy szczegóły krok po kroku, aby lepiej zrozumieć kompresję DDOS. Na początku wyjaśniamy ogólny efekt kompresji systemu, który mówi nam o realistycznej kompresji osiągniętej w systemie Data Domain, ilości danych użytkownika, ilości zużytej przestrzeni fizycznej i ich stosie. W tym dokumencie współczynnik ten jest nazywany "efektywnym współczynnikiem kompresji systemu". DDOS przeprowadza deduplikację w trybie wewnętrznym i śledzi statystyki oryginalnych segmentów danych użytkownika, unikatowych segmentów danych po deduplikacji oraz efekt kompresji lokalnej w unikalnych segmentach danych. Te statystyki kompresji wbudowanej służą do pomiaru efektu kompresji wbudowanej. Dla każdego zapisu mogą być mierzone wbudowane statystyki kompresji. Ponadto DDOS śledzi statystyki na różnych poziomach; plików, MTree i całego systemu.
Zawartość tego dokumentu może być stosowana do wszystkich wersji DDOS do momentu opublikowania tego dokumentu, do DDOS 7.13. Nie ma gwarancji, że wszystkie dane będą poprawne w przyszłych wersjach. W wersjach wcześniejszych niż 5.0 cały system ma tylko jedno drzewo MTree, a termin "mtree" nie jest wyraźnie wywoływany.
Ogólny efekt kompresji w całym systemie jest mierzony efektywnym współczynnikiem kompresji systemu, czyli stosunkiem rozmiaru danych użytkownika do rozmiaru używanej przestrzeni fizycznej. Jest on zgłaszany przez polecenie wiersza polecenia filesys show compression (FSC) (odpowiednie informacje są również dostępne w interfejsie użytkownika). Przykładowe dane wyjściowe FSC są pokazane poniżej:
# filesys show compression
From: 2023-12-31 03:00 To: 2024-01-07 03:00
Active Tier:
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:* 6439.6 113.4 - - 56.8x (98.2)
Written:
Last 7 days 135421.3 1782.0 35.1x 2.2x 76.0x (98.7)
Last 24 hrs 532.5 1.5 334.3x 1.1x 356.5x (99.7)
---------------- -------- --------- ----------- ---------- -------------
* Does not include the effects of pre-comp file deletes/truncates
since the last cleaning on 2024/01/05 11:34:13.
Efektywny współczynnik kompresji systemu jest podawany w wierszu 1 sekcji wyników w danych wyjściowych interfejsu wiersza poleceń. Wiersz jest wyróżniony powyżej. Łączny rozmiar danych użytkownika jest oznaczony jako "Przed kompresją". Całkowita wykorzystana przestrzeń fizyczna (zarówno przez dane, jak i metadane) jest oznaczona jako "Post-Comp".
Liczba "Pre-Comp" i liczba "Post-Comp" są odczytywane w czasie wykonywania. FSC domyślnie synchronizuje cały system, a następnie wysyła zapytanie dotyczące tych dwóch liczb. Te dwie liczby są mierzone w taki sam sposób, jak w przypadku polecenia "filesys show space".
Efektywny współczynnik kompresji systemu = Pre-Comp/Post-Comp
Pozostała część danych wyjściowych FSC opisuje wbudowane statystyki kompresji i omówimy je później.
Istnieje kilka operacji, które mogą wpłynąć na efektywny współczynnik kompresji systemu:
Szybka kopia
Gdy szybka kopia jest wykonywana z pliku w aktywnej przestrzeni nazw (nie migawki), jest to idealna deduplikacja, ponieważ nie jest potrzebna dodatkowa przestrzeń fizyczna dla pliku docelowego. Szybka kopia polega na zwiększeniu rozmiaru danych użytkownika bez zużywania dodatkowej przestrzeni fizycznej. Zwiększa to efektywny współczynnik kompresji systemu. W przypadku wykonywania wielu szybkich kopii efektywny współczynnik kompresji systemu może stać się sztucznie wysoki.
Wirtualne syntetyczne
Wirtualne syntetyczne kopie zapasowe wykazują zwykle wysoki efektywny współczynnik kompresji systemu. Dzieje się tak, ponieważ wirtualne syntetyczne tworzą logiczne pełne kopie zapasowe, ale przesyłają tylko zmienione lub nowe dane do systemów Data Domain. Wpływ wirtualnych syntetycznych na efektywny współczynnik kompresji systemu jest podobny do efektu fastcopy.
Zastępuje
Nadpisywania zużywają więcej miejsca fizycznego, ale nie zwiększają logicznego rozmiaru zestawu danych, dlatego nadpisywania obniżają efektywny współczynnik kompresji systemu.
Przechowywanie rzadkich plików
Pliki rozrzedzone zawierają duże „dziury”, które są zliczane w rozmiarze logicznym, ale nie zajmują miejsca fizycznego z powodu kompresji. W rezultacie współczynnik efektywnej kompresji systemu może wydawać się wysoki.
Przechowywanie małych plików
DDOS dodaje prawie 1 KB narzutu do każdego pliku dla niektórych wewnętrznych metadanych. Gdy system przechowuje znaczną liczbę małych plików (o rozmiarze mniejszym niż 1 KB lub wyrażonych w jednocyfrowych kilobajtach), narzut metadanych obniża efektywny współczynnik kompresji.
Przechowywanie wstępnie skompresowanych lub zaszyfrowanych plików
Kompresja i szyfrowanie mogą zwiększyć poziom zmiany danych i zmniejszyć możliwość deduplikacji. Takie pliki zwykle nie mogą być dobrze zdeduplikowane i obniżyć efektywny współczynnik kompresji systemu.
Usuwa
Usuwanie zmniejsza logiczny rozmiar systemu, ale system nie odzyskuje odpowiadającej mu niewykorzystanej przestrzeni aż do momentu uruchomienia odśmiecania pamięci. Wiele usuniętych plików powoduje, że współczynnik kompresji jest niski do momentu uruchomienia odzyskiwania pamięci (GC).
Odśmiecanie pamięci (GC) lub czyszczenie
GC odzyskuje miejsce zajmowane przez segmenty danych, które nie są już widoczne dla żadnego pliku. Jeśli w ostatnim czasie usunięto wiele plików, GC może zwiększyć współczynnik kompresji systemu poprzez zmniejszenie wykorzystania miejsca fizycznego.
Agresywne wykonywanie migawek
Wykonując migawkę obiektu MTree, nie zmieniamy rozmiaru logicznego zestawu danych. Jednak wszystkie segmenty danych, do których odwołuje się migawka, muszą być zablokowane, nawet jeśli wszystkie pliki przechwycone przez migawkę zostaną usunięte po wykonaniu migawki. GC nie może odzyskać miejsca, które jest nadal potrzebne przez migawki; Dlatego posiadanie dużej liczby migawek może sprawić, że efektywny współczynnik kompresji systemu będzie wyglądał na niski. Migawki są jednak przydatnymi narzędziami do odzyskiwania danych po awarii. Zawsze w razie potrzeby warto wykonywać migawki i konfigurować odpowiednie harmonogramy ich wykonywania.
DDOS przeprowadza deduplikację w trybie inline, ponieważ dane są zapisywane w systemie. Śledzi efekty wbudowanej deduplikacji i kompresji lokalnej dla każdego zapisu i gromadzi statystyki na poziomie pliku. Statystyki wbudowanej kompresji dla poszczególnych plików są dalej agregowane na poziomie drzewa MTree i na poziomie systemu. Kompresja jest mierzona na podstawie trzech liczb w statystykach wbudowanych:
Na podstawie powyższych trzech liczb DDOS definiuje dwa dodatkowe współczynniki kompresji o drobnej ziarnistości:
Zgromadzone statystyki kompresji wbudowanej są częścią metadanych pliku w DDOS i są przechowywane w i-węźle pliku. DDOS zapewnia narzędzia do sprawdzania wbudowanych kompresji na wszystkich trzech poziomach; plik, MTree i cały system. Szczegółowo opiszemy je w kolejnych sekcjach.
3.1 Kompresja
plików Kompresja pliku może być sprawdzona za pomocą polecenia CLI "filesys show compression <path>", które zgłasza skumulowane statystyki kompresji przechowywane w i-węźle pliku. Po określeniu katalogu statystyki kompresji wbudowanej wszystkich plików w tym katalogu są sumowane i raportowane. W danych wyjściowych CLI raw_bytes jest oznaczony jako "Original Bytes"; pre_lc_size jest oznaczony jako "Globalnie skompresowany"; post_lc_bytes jest oznaczony jako "Lokalnie skompresowany"; pozostałe koszty ogólne są zgłaszane jako "Metadane". Te dwa przykłady są przechwytywane z rzeczywistego DD:
Przykład 1: Statystyki wbudowanej kompresji pliku
# filesys show compression /data/col1/main/dir1/file_1
Total files: 1; bytes/storage_used: 7.1
Logical Bytes: 53,687,091,200
Original Bytes: 11,463,643,380
Globally Compressed: 4,373,117,751
Locally Compressed: 1,604,726,416
Meta-data: 18,118,232
Przykład 2: Statystyki kompresji wbudowanej wszystkich plików w katalogu, w tym wszystkich podkatalogów
# filesys show compression /data/col1/main/dir1
Total files: 13; bytes/storage_used: 7.1
Logical Bytes: 53,693,219,809
Original Bytes: 11,501,978,884
Globally Compressed: 4,387,212,404
Locally Compressed: 1,608,444,046
Meta-data: 18,241,880
System zgłasza ogólny współczynnik kompresji w powyższych danych wyjściowych interfejsu wiersza polecenia jako "bajty/storage_used". Informacje te należy jednak interpretować ostrożnie, ponieważ mogą one być mylące z różnych powodów. Jednym z nich jest to, że pre_lc_size i post_lc_size są rejestrowane w czasie przetwarzania danych. Gdy plik, który pierwotnie dodał te segmenty, zostanie usunięty, liczba unikatowych segmentów danych w pozostałym pliku powinna zostać zwiększona.
Załóżmy na przykład, że kopia zapasowa pliku sample.file została utworzona w Data Domain, a w pierwszej kopii zapasowej informacje o kompresji pliku to pre_lc_size=10GiB, post_lc_size=5Gib.
Następnie załóżmy, że dane tego pliku są unikatowe i nie są udostępniane żadnemu innemu plikowi. Załóżmy ponadto, że podczas tworzenia drugiej kopii zapasowej pliku plik otrzymuje idealną deduplikację, w której zarówno pre_lc_size, jak i post_lc_size powinny wynosić zero, ponieważ wszystkie segmenty pliku już istniały w systemie. Po usunięciu pierwszej kopii zapasowej druga kopia zapasowa pliku staje się jedynym plikiem, który odwołuje się do 5 GiB segmentów danych. W takim przypadku najlepiej byłoby, gdyby pre_lc_size i post_lc_size pliku w drugiej kopii zapasowej zostały zaktualizowane z wartości zero odpowiednio do 10 GiB i 5 GiB. Nie ma jednak sposobu, aby wykryć, dla których plików należy to zrobić, więc wbudowane statystyki kompresji istniejących plików pozostają niezmienione.
Kolejnym czynnikiem, który wpływa na powyższe liczby, są skumulowane statystyki. Gdy plik otrzymuje wiele nadpisań, niemożliwe jest śledzenie, w jakim stopniu skumulowane statystyki odzwierciedlają zapisy, które wprowadziły dane na żywo. W związku z tym przez długi czas statystyki kompresji wbudowanej mogą być traktowane tylko jako heurystyka do przybliżonego oszacowania kompresji określonego pliku.
Innym faktem, na który warto zwrócić uwagę, jest to, że wbudowana kompresja pliku nie może być mierzona w dowolnym przedziale czasu. Statystyki kompresji wbudowanej pliku są wynikiem skumulowanym i obejmują wszystkie zapisy, jakie kiedykolwiek otrzymał plik. Gdy plik otrzyma wiele nadpisań, raw_bytes może być znacznie większy niż logiczny rozmiar pliku. W przypadku plików rzadkich rozmiary plików mogą być większe niż "Oryginalne bajty".
3.2 Kompresja
MTree Kompresję konkretnego drzewa MTreemożemy sprawdzić za pomocą metody "mtree show compression" (MSC) Polecenie CLI. Wartości bezwzględne statystyk kompresji wbudowanej kumulują się przez cały okres istnienia obiektu MTree. Biorąc pod uwagę, że żywotność MTree może trwać wiele lat, wartości te z czasem stają się coraz mniej pouczające. Aby rozwiązać ten problem, używamy wielkości zmian (delta) statystyk kompresji wbudowanej i raportujemy kompresję tylko dla określonych przedziałów czasu. Podstawowe podejście polega na tym, że okresowo zrzucamy statystyki kompresji MTree do dziennika. Gdy klient wysyła zapytanie o kompresję MTree za pomocą polecenia MSC, używamy dziennika do obliczenia różnic liczb do raportowania kompresji. Domyślnie MSC raportuje kompresję z ostatnich 7 dni i ostatnich 24 godzin, chociaż można określić dowolny okres zainteresowania.
Aby to zademonstrować, załóżmy, że istnieje następujący dziennik dla drzewa MTree A:
3:00AM, raw_bytes=11000GB, pre_lc_size=100GB, post_lc_size=50GB 4:00AM, raw_bytes=12000GB, pre_lc_size=200GB, post_lc_size=100GB
Wtedy kompresja MTree A dla tej godziny wynosi:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
Powyższe obliczenie współczynnika kompresji nie ma wpływu na rozmiar zestawu danych. Na przykład powyższy obiekt MTree może zawierać tylko 500 GB danych logicznych.
MSC obsługuje opcje "daily" i "daily-detailed", podobnie jak polecenie "filesys show compression". Jeśli określono wartość "daily", polecenie zgłasza dzienną kompresję w sposób kalendarzowy. Używa codziennych wartości delta raw_bytes i post_lc_size do obliczania dziennego współczynnika kompresji. Gdy określono wartość "daily-detailed", polecenie pokazuje wszystkie trzy delty (odpowiednio raw_bytes, pre_lc_size i post_lc_size) dla każdego dnia; Oblicza również g_comp i l_comp wraz z całkowitym współczynnikiem kompresji.
Przykładowe dane wyjściowe z tych systemów znajdują się w załączniku.
3.3 Kompresja
systemu Kiedy już zrozumiemy, w jaki sposób kompresja jest raportowana na MTrees, łatwo jest rozszerzyć tę koncepcję na cały system. Wbudowane gromadzenie i raportowanie wbudowanych statystyk kompresji dla całego systemu jest dokładnie takie samo jak w przypadku obiektów MTrees. Jedyną różnicą jest zakres, ponieważ jeden znajduje się w konkretnym MTree, a drugi w całym systemie. Wyniki można sprawdzić za pomocą polecenia "filesys show compression". Przykład tego można znaleźć w sekcji 2. Kompresja systemu "ostatnie 7 dni" i "ostatnie 24 godziny" jest podawana w dwóch ostatnich wierszach sekcji wyników w danych wyjściowych FSC.
W przypadku DD z zaimplementowaną warstwą chmury pamięć masowa jest rozdzielona na warstwę aktywną i warstwę chmurową, które są dwiema niezależnymi domenami deduplikacji. Użytkownicy mogą wstrzykiwać dane tylko do warstwy aktywnej. Później funkcje ruchu danych DDOS mogą być używane do migrowania danych z warstwy aktywnej do warstwy chmury. W związku z tym pomiar i raportowanie przestrzeni i kompresji są obsługiwane niezależnie na każdym poziomie. Jednak na poziomie plików nie rozróżniamy według warstwy i nie raportujemy statystyk kompresji wbudowanej; są one dokładnie takie same, jak te, które opisaliśmy w sekcji 3.1.
Ostatnim tematem, na który należy zwrócić uwagę, są niektóre cechy charakterystyczne deduplikacji, która w wielu dokumentach Data Domain jest nazywana "kompresją globalną". Chociaż zawiera słowo "kompresja", jest zupełnie inna niż tradycyjna koncepcja kompresji, która jest również dostarczana przez DDOS pod nazwą "kompresja lokalna".
Kompresja lokalna zmniejsza rozmiar fragmentu danych przy użyciu określonego algorytmu (niektóre rodzaje danych nie są kompresowalne i zastosowanie na nich algorytmów kompresji może nieznacznie zwiększyć rozmiar danych). Zwykle, po podjęciu decyzji o algorytmie, same dane są jedynym czynnikiem współczynnika kompresji.
Jednak deduplikacja jest inna - nie jest to koncepcja lokalna, jest "globalna". Segment danych przychodzących jest deduplikowany względem wszystkich istniejących segmentów danych w deduplikowanej domenie, która obejmuje wszystkie dane w systemach Data Domain spoza chmury. Sam segment danych nie ma znaczenia w procedurze deduplikacji.
W praktyce rzadko spotykamy się z wysokim współczynnikiem deduplikacji w początkowej kopii zapasowej zestawu danych. W początkowych kopiach zapasowych często istotna redukcja danych wynika z kompresji lokalnej. Gdy kolejne kopie zapasowe trafiają do Data Domain, deduplikacja pokazuje swoją siłę i staje się dominującym czynnikiem kompresji. Skuteczność deduplikacji polega na tym, że szybkość zmian zestawu danych jest niska w przypadku kolejnych kopii zapasowych. Z tego powodu zestawy danych o wysokich współczynnikach zmian nie mogą być dobrze deduplikowane. Gdy aplikacja do tworzenia kopii zapasowych wstawia własne fragmenty metadanych (nazywane znacznikami przez Data Domain) do obrazów kopii zapasowych z dużą częstotliwością, może również nie uzyskać dobrego współczynnika deduplikacji. Nasze techniki posługiwania się markerami mogą czasami pomóc, ale nie zawsze.
Biorąc pod uwagę te obserwacje, czego możemy się spodziewać?
Pomiar kompresji jest trudny w deduplikowanych systemach plików, ale jest jeszcze trudniejszy w deduplikowanych systemach plików o strukturze dziennika. Musimy zrozumieć, jak działa deduplikacja i jak śledzone są statystyki kompresji. Współczynniki kompresji są przydatnymi informacjami ułatwiającymi zrozumienie zachowania konkretnego systemu. Efektywny współczynnik kompresji systemu jest najważniejszą, najbardziej wiarygodną i pouczającą miarą. Wbudowane statystyki kompresji również mogą być pomocne, ale w niektórych okolicznościach mogą być tylko heurystyką.
Dodatek: Przykładowe dane wyjściowe "mtree show compression" Załóżmy
, że istnieje drzewo MTree przechowujące 254792,4 GiB danych. Otrzymano 4379,3 GiB nowych danych w ciągu ostatnich 7 dni i 78,4 GiB w ciągu ostatnich 24 godzin (można określić inne przedziały czasu). Opcja „daily” raportuje statystyki kompresji wbudowanej dla ostatnich 33 dni. Gdy dostępna jest opcja "Daily-Detailed", całkowite współczynniki kompresji są dalej wyszczególniane przez podzielenie ich na globalne i lokalne współczynniki kompresji.
Dane wyjściowe listy MTree:
# mtree list /data/col1/main Name Pre-Comp (GiB) Status --------------- -------------- ------ /data/col1/main 254792.4 RW --------------- -------------- ------ D : Deleted Q : Quota Defined RO : Read Only RW : Read Write RD : Replication Destination IRH : Retention-Lock Indefinite Retention Hold Enabled ARL : Automatic-Retention-Lock Enabled RLGE : Retention-Lock Governance Enabled RLGD : Retention-Lock Governance Disabled RLCE : Retention-Lock Compliance Enabled M : Mobile m : Migratable
# mtree show compression /data/col1/main
From: 2023-09-07 12:00 To: 2023-09-14 12:00
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
------------- -------- --------- ----------- ---------- -------------
Written:
Last 7 days 4379.3 883.2 3.4x 1.5x 5.0x (79.8)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
------------- -------- --------- ----------- ---------- -------------
W opcji "codziennie":
# mtree show compression /data/col1/main daily
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100
Z opcją "daily-detailed":
# mtree show compression /data/col1/main daily-detailed
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
3.5x 4.1x 4.3x 3.6x 3.8x 3.3x 3.4x 3.7x Global-Comp Factor
1.4x 1.5x 1.5x 1.5x 1.5x 1.4x 1.5x 1.5x Local-Comp Factor
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
80.2 83.7 84.1 81.3 82.3 78.9 80.0 81.5 Reduction %
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
3.3x 3.3x 3.0x 3.0x 3.3x 4.1x 3.6x 3.3x
1.4x 1.5x 1.5x 1.5x 1.4x 1.5x 1.4x 1.5x
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
79.0 79.0 77.6 77.7 78.2 84.3 80.9 79.2
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
4.4x 3.7x 2.6x 3.8x 3.5x 3.9x 3.2x 3.5x
1.3x 1.5x 1.6x 1.5x 1.4x 1.5x 1.5x 1.5x
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
82.1 82.2 76.8 82.2 80.3 82.7 78.2 80.7
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
3.4x 3.1x 3.2x 3.4x 3.3x 3.4x 4.1x 3.3x
1.4x 1.5x 1.5x 1.4x 1.4x 1.5x 1.6x 1.5x
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
79.5 78.2 78.6 79.2 79.2 80.4 84.2 79.6
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
3.1x 3.4x 3.2x 3.7x 3.4x .3x
1.5x 1.4x 1.5x 1.4x 1.5x 1.5x
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
78.2 79.3 78.7 81.1 79.5 79.4
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100