Data Domain: Rozmiar plików do usunięcia jest szacunkowy

Często występuje zamieszanie co do wartości GiB do wyczyszczenia w systemie Data Domain i niewłaściwe oczekiwania co do ilości miejsca, które zostanie odzyskane po uruchomieniu czyszczenia.

Podana liczba "możliwych do wyczyszczenia GiB" jest czysto szacunkowa i nie jest możliwe uzyskanie dokładnej wartości ilości miejsca, które zostanie odzyskane przez uruchomienie czyszczenia, ze względu na wybory technologiczne dokonane podczas opracowywania systemu plików Data Domain.

Poniżej znajduje się zwięzłe wyjaśnienie, dlaczego szacunki dotyczące przestrzeni możliwej do oczyszczenia mogą się znacznie różnić od rzeczywistej przestrzeni odzyskanej. Istnieją jednak inne czynniki, które nie zostały tutaj uwzględnione, co może sprawić, że szacunki i ilość miejsca na dysku naprawdę zwolnionego po uruchomieniu czyszczenia będą się znacznie różnić
 

Gdy dane są pozyskiwane przez system Data Domain, wartość po kompresji jest obliczana i przechowywana jako dane statyczne dla każdego pliku. Możliwe do wyczyszczenia wartości to po prostu suma wartości po kompresji dla wszystkich usuniętych plików od ostatniego uruchomienia czyszczenia DD do końca.
 

Wartość Możliwe do wyczyszczenia staje się niedokładna, jeśli segmenty usuniętych plików zostały użyte do deduplikacji danych w innych plikach, które nie zostały usunięte. Jeśli istnieje jeden plik odnoszący się do istniejącego unikatowego segmentu, proces czyszczenia DD nie uzna tych segmentów za podlegające odzyskaniu. Więc nawet jeśli post-comp pliku został dodany w liczniku "Cleanable GiB" tak, jakby wszystkie jego unikatowe segmenty miały zostać usunięte, niektóre (lub wiele) mogą nie być spowodowane ponownym użyciem przez inne pliki.
 

Bardziej szczegółowy przykład pokazujący ten efekt jest następujący:

Załóżmy, że masz 5 plików, dodawanych jeden po drugim do systemu Data Domain, bez żadnych innych danych.

Ponieważ pierwsze pliki 100 GB zawierały wszystkie unikatowe dane, ich współczynnik kompresji wynosi 1x (zakładając, że pierwszy plik nie miał żadnej nadmiarowości w samym pliku). Pliki 2–5 były w stanie deduplikować dane pierwszego pliku i każdy ze starszych plików w miarę ich dodawania, przy czym każdy z nich zyskiwał coraz większą deduplikację ze względu na rosnącą liczbę plików, względem których można było usunąć duplikaty.

File 1: precomp: 100 GB postcomp: 100 GB compression ratio: 1x
File 2: precomp: 100 GB postcomp:  50 GB compression ratio: 2x
File 3: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 4: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 5: precomp: 100 GB postcomp:   1 GB compression ratio: 100x

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         500           -      -                -
/backup: post-comp      1000         201         799    20%                0
----------------   ---------   ---------   ---------   ----   --------------

Przykład 1. Stan po usunięciu pierwszych 3 plików z /backup:
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         200           -      -                -
/backup: post-comp      1000         201         799    20%              175
----------------   ---------   ---------   ---------   ----   --------------

Jeśli po wykonaniu procesu czyszczenia zostanie uruchomione czyszczenie, być może uda się odzyskać 125 zamiast pełnych 175 możliwych do wyczyszczenia. Wynika to z faktu, że ostatnie 2 pliki współdzielą segmenty z plikami 1-3.  Czyszczenie nie spowoduje odzyskania pozostałych 50 GB miejsca, ponieważ segmenty te są nadal używane przez pliki 3–5.
 

Przykład 2: Korzystając z tego samego punktu wyjścia, co w przykładzie 1, załóżmy, że plik 1 został usunięty, następnie wykonano szybką kopię na całym folderze /backup (tj. wszystkich 5 plikach), a następnie usunięto pliki 2-4. 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         201         799    20%              200
----------------   ---------   ---------   ---------   ----   --------------

Wartość "Rozmiar GiB" dla pre-kompozycji pochodzi z (500-100)=400*2=800, co daje 500 dla 5 oryginalnych plików, odejmowanie 100 dla usunięcia pliku 1 daje 400 GiB.  Następnie 400 GiB pomnożone przez 2 ze względu na szybką kopię dla wszystkich 4 pozostałych plików.

Zauważ, że używana przestrzeń po kompozycji jest nadal taka sama, ponieważ kopia pliku dodaje tylko niewielką ilość miejsca, składającą się ze wskaźników metadanych do oryginalnych danych. Wykorzystanie miejsca nie zmieniło się pomimo usunięcia pliku 1, ponieważ nie uruchomiono polecenia "czysty start filesys" (w celu zainicjowania czyszczenia). 
 

Po Clean zobaczymy:
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         176         824    18%                0
----------------   ---------   ---------   ---------   ----   --------------

Należy pamiętać, że chociaż 200 GB było oznaczone jako możliwe do wyczyszczenia, w rzeczywistości wyczyszczono tylko 25 GB. Wartość "Możliwych do wyczyszczenia GiB" wynosiła 200, ponieważ rozmiar pliku "po kompilacji" plików od 1 do 4 wynosił 200 GB.  Usunięto tylko "Plik 1", który miał 100 GB, ale 75 GB było nadal używane przez pozostałe 4 pliki (z powodu deduplikacji).  

Może się to wydawać dziwne, ponieważ "Plik od 2" do "Plik 4" również został usunięty, ale pamiętaj, że chociaż system pokaże "Plik od 2" do "Plik 4" jako usunięty, rzeczywiste segmenty danych dla tych plików nie mogły zostać usunięte, ponieważ pliki te zostały szybko skopiowane do innego folderu.   Dopiero po usunięciu wszystkich wersji fastcopy można w pełni odzyskać miejsce poprzez czyszczenie.

Ponieważ możliwe do oczyszczenia GiB są tylko "oszacowaniem" i mogą nie być dokładne, czasami mogą odzwierciedlać duży lub taki sam rozmiar jak fizyczna pojemność Data Domain.

Może to prowadzić do niejasności, czy zezwolić na uruchomienie zaplanowanego czyszczenia DDFS, czy uruchomić je ręcznie, jeśli wykorzystanie miejsca DDFS zbliża się do 100% ze względu na to, że GiB do oczyszczenia są wyświetlane w pobliżu lub mają taką samą wartość jak "/data: post-comp".

Aby zapewnić lepszy i bardziej niezawodny sposób szacowania ilości wolnego miejsca na dysku, które można odzyskać podczas uruchamiania, począwszy od DDOS 7.7.x można teraz określić w interfejsie wiersza polecenia rzeczywistą całkowitą ilość miejsca do wyczyszczenia, którą następny GC w warstwie aktywnej będzie w stanie odzyskać. Oto podsumowanie wiersza poleceń:
 

# filesys cleanable-space calculate
Cleanable space calculation started. Use 'filesys cleanable-space watch' to monitor progress.

Proces będzie działał tak samo jak zwykły GC, przechodząc przez fazy od 1 do 4, ale pomijając fazę 5 (kopiowanie), która skutecznie kopiuje kontenery do przodu w celu odzyskania martwego miejsca na dysku. W związku z tym zwrócenie wartości zajmie tyle czasu, ile zajmuje zwykłemu GC ukończenie czystych faz od 1 do 4, więc nie jest to coś, co należy regularnie uruchamiać w celu uzyskania zaktualizowanego oszacowania, ale tylko w razie potrzeby. Innymi słowy, polecenie "filesys cleanable-space calculate" uruchomi GC w warstwie aktywnej, pomijając tylko część, w której odzyskuje miejsce.

Proces może być monitorowany w następujący sposób:
 

# filesys cleanable-space watch
Beginning 'filesys cleanable-space calculation' monitoring.  Use Control-C to stop monitoring.

Cleaning: phase 1 of 4 (pre-merge)
  100.0% complete, 96233 GiB free; time: phase  0:02:07, total  0:02:07

Cleaning: phase 2 of 4 (pre-analysis)
  100.0% complete, 96233 GiB free; time: phase  0:06:51, total  0:08:59

Cleaning: phase 3 of 4 (pre-enumeration)
  100.0% complete, 96233 GiB free; time: phase  0:00:20, total  0:09:20

Cleaning: phase 4 of 4 (pre-select)
  100.0% complete, 96233 GiB free; time: phase  0:00:25, total  0:09:46

Po zakończeniu można uzyskać dostęp do możliwego do oczyszczenia wyniku pomiaru:

# filesys cleanable-space status

Cleanable space on active tier is 94649698202 bytes. Last calculated on 2023/08/25 03:29:51
Cleanable space calculation finished at 2023/08/25 03:29:51.

W powyższym przykładowym teście, jeśli DD GC ma zostać uruchomiony teraz, zwolni to 94649698202 bajty. To 88,1 GiB, podczas gdy w momencie obliczeń szacunki zgłoszone przez "df" w laboratorium użytym przez DD wynosiły 41,9 GiB. Oczywiście, w miarę wprowadzania zmian w FS (nowe kopie zapasowe, więcej usunięć, tworzenie i wygasanie migawek itp.) obliczenia zostaną wyłączone.

W razie potrzeby, aby zatrzymać powyższy proces, można użyć poniższego polecenia:

# filesys cleanable-space stop

The 'filesys cleanable-space stop' command stops calculating cleanable space in the system.
Are you sure? (yes|no) [no]: yes

ok, proceeding.

# filesys cleanable-space status
Cleanable space on active tier is 2607064 bytes. Last calculated on 2021/06/27 23:23:05
Cleanable space calculation started at 2021/06/27 23:27:58 and was aborted at 2021/06/27 23:28:19.
Cleaning was aborted by user.

Uwaga: ten interfejs wiersza poleceń dotyczy tylko warstwy aktywnej DD. Nie ma równoważnego procesu obliczania możliwości czyszczenia dla jednostki chmury DD, która ma własne oszacowanie, obarczone takimi samymi niepewnościami, jak opisane powyżej.