Data Domain: Wskazówki dotyczące kompresji Data Domain

Techniki kompresji stosowane w Data Domain wykorzystują najnowocześniejsze techniki zmniejszania fizycznej przestrzeni wymaganej przez dane kopii zapasowych. Technologie i pomiary poziomów kompresji są złożonymi zagadnieniami.

W tym artykule omówiono niektóre terminologie, kompromisy i miary, aby lepiej wyjaśnić używany typ kompresji oraz inne aspekty kompresji w środowisku Data Domain.

DOTYCZY: Wszystkie modele Data Domain

Wprowadzenie:

Ostatnia aktualizacja: styczeń 2024 r.

• Kompresja to technologia redukcji danych, która ma na celu przechowywanie zestawu danych przy użyciu mniejszej ilości miejsca fizycznego.
• W systemach Data Domain (DDOS) deduplikacja i kompresja lokalna są wykonywane w celu kompresji danych użytkownika. Deduplikacja lub "deduplikacja" służy do identyfikowania nadmiarowych segmentów danych i przechowywania tylko unikatowych segmentów danych.
• 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żna zmierzyć.

W tym artykule omówiono szczegółowe informacje krok po kroku, które pomogą zrozumieć kompresję DDOS.

• Na początku wyjaśniony jest 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 stosunku.
• W tym artykule 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: Pliki MTreesi całego systemu.

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 jeden mtree oraz termin mtree nie jest wyraźnie wywoływany.

Kompresja: Ogólny efekt systemu:

Ogólny efekt kompresji dla całego systemu jest mierzony efektywnym współczynnikiem kompresji, czyli stosunkiem rozmiaru danych użytkownika do rozmiaru używanej przestrzeni fizycznej. Informuje o tym "filesys show compression" (FSC) CLI (odpowiednie informacje są również dostępne w interfejsie użytkownika). Przykładowe dane wyjściowe FSC jest pokazany 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 niejawnie synchronizuje cały system, a następnie odpytuje dwie liczby.
    • Te dwie liczby są mierzone w taki sam sposób jak "filesys show space" polecenie.
    • Efektywny współczynnik kompresji systemu = Przed kompresją/po kompresji

Istnieje kilka operacji, które mogą wpłynąć na efektywny współczynnik kompresji systemu:

• Szybka kopia
  • Kiedy fastcopy jest wykonywana z pliku w aktywnej przestrzeni nazw (nie migawki), jest to doskonała deduplikacja, ponieważ nie jest potrzebna dodatkowa przestrzeń fizyczna dla pliku docelowego. Efekt fastcopy polega na zwiększeniu rozmiaru danych użytkownika bez zajmowania dodatkowej przestrzeni fizycznej. Zwiększa to efektywny współczynnik kompresji systemu. Gdy wiele fastcopies efektywny współczynnik kompresji systemu może stać się sztucznie zawyżony.
• 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 syntetyków na efektywny współczynnik kompresji systemu jest podobny do wpływu fastcopy.
• Zastępuje
  • Nadpisywanie zajmuje więcej miejsca fizycznego, ale nie zwiększa logicznego rozmiaru zestawu danych, dlatego nadpisywanie obniża 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
  • Gdy migawka Mtree , rozmiar logiczny zestawu danych nie ulega zmianie. 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, posiadanie wielu 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. W razie potrzeby zawsze rób zdjęcia lub konfiguruj ich odpowiednie harmonogramy.

Kompresja: Statystyki inline:

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 w mtree na poziomie systemu i na poziomie systemu. Kompresja jest mierzona na podstawie trzech liczb w statystykach wbudowanych:

• Długość każdego zapisu: raw_bytes 
• The length of all unique segments: pre_lc_size
• Długość lokalnie skompresowanych unikatowych segmentów: post_lc_size

• • Kompresja globalna (g_comp)
    • Równa się (raw_bytes/pre_lc_size) i odzwierciedla współczynnik deduplikacji
  • Kompresja lokalna (l_comp)
    • Równa się (pre_lc_size/post_lc_size) i odzwierciedla efekt algorytmu kompresji lokalnej

Skumulowane statystyki kompresji są częścią metadanych pliku w DDOS i są przechowywane w pliku inode. DDOS zapewnia narzędzia do sprawdzania wbudowanych kompresji na wszystkich trzech poziomach; Plik MTreei w całym systemie. Zostały one szczegółowo opisane w poniższych sekcjach.

Kompresja plików:

• • Kompresję pliku można sprawdzić za pomocą polecenia "filesys show compression <path>" CLI, które zgłasza skumulowane statystyki kompresji zapisane w pliku inode.
  • 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 "Oryginalne bajty", 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". Dwa przykłady są przechwytywane z produkcyjnego 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 wbudowanej 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 powodów jest to, że pre_lc_size i post_lc_size są rejestrowane w momencie przetwarzania operacji na 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 przykładowego pliku pliku jest tworzona w Data Domain, a w pierwszej kopii zapasowej informacje o kompresji pliku to pre_lc_size= 10 GiB, post_lc_size= 5 Gib.

• • • Następnie załóżmy, że dane tego pliku są unikatowe i nie są udostępniane żadnemu innemu plikowi.
    • W drugiej kopii zapasowej pliku załóżmy ponadto, że plik otrzymuje idealną deduplikację, tak aby oba pre_lc_size i post_lc_size powinna 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 należy zaktualizować z obu wartości zero do odpowiednio 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 plików 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".

Kompresja MTree:

• • Kompresja określonego mtree można sprawdzić za pomocą przycisku "mtree show compression" (MSC) Polecenie CLI.
  • Wartości bezwzględne wbudowanych statystyk kompresji kumulują się przez cały okres istnienia MTree.
  • Biorąc pod uwagę, że okres życia MTree może trwać wiele lat, wartości te z czasem stają się coraz mniej pouczające.
  • Aby rozwiązać ten problem, używana jest wielkość zmian (delty) wbudowanych statystyk kompresji i raportowanie kompresji tylko w określonych przedziałach czasu.
  • Podstawowe podejście jest takie, że MTree Statystyki kompresji wbudowanej są okresowo zrzucane do dziennika.
  • Gdy klient wysyła zapytanie o kompresję MTree za pomocą MSC dziennik służy do obliczania różnic liczb na potrzeby raportowania kompresji.
  • Domyślnie MSC Kompresja raportów z ostatnich 7 dni i ostatnich 24 godzin, z możliwością określenia dowolnego interesującego okresu.

Aby to zademonstrować, załóżmy, że następujący dziennik dla MTree Odpowiedź:

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

Następnie kompresja MTree A na tę godzinę to:

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 "filesys show compression" polecenie.
  • Jeśli określono wartość "daily", polecenie zgłasza dzienną kompresję w sposób kalendarzowy.
  • Wykorzystuje dzienne delty raw_bytes i post_lc_size , aby obliczyć dzienny współczynnik kompresji.
  • Jeśli określono wartość "daily-detailed", polecenie pokazuje wszystkie trzy delty (z atrybutu raw_bytes, pre_lc_sizei post_lc_size, odpowiednio) za każdy dzień. Oblicza się w nim również g_comp i l_comp obok całkowitego współczynnika kompresji.

Przykładowe dane wyjściowe z tych systemów znajdują się w załączniku poniżej.

Kompresja systemu:

• • Po tym, jak kompresja jest raportowana MTrees jest zrozumiałe, łatwo jest rozszerzyć koncepcję na cały system.
  • Wbudowane gromadzenie i raportowanie wbudowanych statystyk kompresji dla całego systemu jest dokładnie takie samo jak w przypadku MTrees.
  • Jedyną różnicą jest zakres, ponieważ jest się w konkretnym MTree, podczas gdy jeden jest nad całym systemem.
  • Wyniki można sprawdzić za pomocą przycisku "filesys show compression" polecenie.
  • 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 pliku FSC danych wyjściowych.

Poziom w chmurze:

• 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 pliku nie ma rozróżnienia według warstwy i raportowania statystyk kompresji w tekście, są one dokładnie takie same jak opisane w sekcji 3.1.

Deduplikacji:

Ostatnim tematem, na który należy zwrócić uwagę, są niektóre cechy charakterystyczne deduplikacji, która w wielu artykułach dotyczących 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, 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 wysoki współczynnik deduplikacji jest rzadko spotykany 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żna się spodziewać:

• Początkowe kopie zapasowe mogą osiągnąć tylko niewielki efektywny współczynnik kompresji systemu, często 2x lub 3x. Deduplikacja zwykle ma niewielkie możliwości pokazania swojej siły w początkowych kopiach zapasowych.
• Globalny współczynnik kompresji przyrostowej kopii zapasowej jest niższy niż współczynnik kompresji odpowiadającej jej pełnej kopii zapasowej. Dzieje się tak, ponieważ przyrostowa kopia zapasowa zawiera tylko zmienione lub nowe pliki w porównaniu z bezpośrednio poprzedzającą ją kopią zapasową. Globalny współczynnik kompresji zależy od procentu nowych danych w przyrostowej kopii zapasowej.
• W niektórych scenariuszach współczynnik deduplikacji pełnej kopii zapasowej (niepoczątkowych) może być również niski. Niektóre często obserwowane scenariusze obejmują:
  • Duża szybkość zmian danych tworzonych w kopii zapasowej
  • Zestaw danych jest zdominowany przez małe pliki (mniej niż 5 MiB)
  • Aplikacje do tworzenia kopii zapasowych dodające wiele blisko rozmieszczonych znaczników
  • Kopie zapasowe baz danych, które są przyrostowe lub używają małego rozmiaru bloku
  • W przypadku zaobserwowania niskiego współczynnika kompresji w pełnej kopii zapasowej przy niskim współczynniku zmiany danych należy sprawdzić, czy ma zastosowanie jeden z powyższych przypadków i czy wymagana jest dalsza analiza.
• Kompresja późniejszego obrazu kopii zapasowej nie zawsze jest lepsza niż początkowego. Kolejne obrazy kopii zapasowych mogą wykazywać wysoki współczynnik deduplikacji, ponieważ początkowe i wcześniejsze obrazy kopii zapasowych już dodały większość danych do systemu. Po usunięciu wszystkich wcześniejszych kopii zapasowych współczynnik kompresji globalnego i lokalnego najwcześniejszego istniejącego obrazu kopii zapasowej może być nadal wysoki, ale oznacza to tylko, że uzyskał on dobrą deduplikację po dodaniu go do systemu. Po usunięciu pliku, który ma wysoki globalny i lokalny współczynnik kompresji i jest ostatnim obrazem zapasowym określonego zestawu danych, może zwolnić więcej miejsca niż rozmiar wyznaczony na podstawie współczynnika kompresji.
• Nie można porównywać współczynników kompresji tego samego zestawu danych w różnych systemach, niezależnie od sposobu dodania zestawu danych do tych systemów. Wynika to z faktu, że każdy system jest niezależną domeną deduplikacji. Nie należy oczekiwać, że dwa różne DD uzyskają takie same lub nawet koniecznie podobne współczynniki kompresji, nawet jeśli ich zestawy danych są takie same.

Podsumowanie:

• Pomiar kompresji jest trudny w deduplikowanych systemach plików, ale jest jeszcze trudniejszy w deduplikowanych systemach plików o strukturze dziennika.
• Należy 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ą.

Załącznik:

Przykładowe dane wyjściowe "mtree show compression" command

• Załóżmy, że istnieje MTree 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.

Pakiet mtree Dane wyjściowe listy:

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

MSC (brak opcji):

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