Data Domain: Rengöringsbar storlek är en uppskattning

Det råder ofta förvirring kring värdet för "Cleanable GiB" som visas i ett Data Domain-system och felaktiga förväntningar på hur mycket utrymme som kommer att återställas vid körning av rensning.

Det angivna antalet "Cleanable GiB" är endast en uppskattning, och det är inte möjligt att få ett exakt värde för hur mycket utrymme som kommer att återställas genom att köra rensning, på grund av de tekniska val som gjordes vid utvecklingen av Data Domain Filesystem.

Nedan följer en kortfattad förklaring till varför uppskattningar av rengöringsbara utrymmen kan skilja sig avsevärt från det faktiska utrymmet som återvunnits. Det finns dock andra faktorer som inte tas med i beräkningen här, vilket kan göra att uppskattningen och mängden diskutrymme som verkligen frigörs när den körs ren skiljer sig avsevärt
 

När data matas in av Data Domain-systemet beräknas värdet efter komprimeringen och lagras som statiska data för varje fil. Värdet för "Cleanable" är helt enkelt summan av värdet efter komprimering för alla borttagna filer sedan den senaste gången DD clean kördes till slutförande.
 

Värdet Cleanable blir felaktigt om filsegmenten för borttagna filer har använts för att deduplicera data i andra filer som inte har tagits bort. Så länge det finns en enda fil som refererar till ett befintligt unikt segment kommer DD-rensningsprocessen inte att överväga att dessa segment ska frigöras. Så även om en fils post-comp lades till i "Cleanable GiB"-räknaren som om alla dess unika segment var på väg att tas bort, kanske vissa (eller många) inte gör det på grund av att de återanvänds av andra filer.
 

Ett mer detaljerat exempel som visar den här effekten följer:

Anta att du har 5 filer, tillagda en efter en i ett Data Domain-system, utan några andra data tidigare på den.

Eftersom de första filerna på 100 GB innehöll alla unika data är dess komprimeringsförhållande 1x (förutsatt att den första filen inte hade någon redundans i själva filen). De 2:a-5:e filerna kunde deduplicera mot den 1:a filens data och var och en av de äldre filerna när de läggs till, var och en fick ökande deduplicering på grund av de ökande filerna att deduplicera mot.

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
----------------   ---------   ---------   ---------   ----   --------------

Exempel 1. Status efter att ha tagit bort de första 3 filerna från /backup:
 

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

Om du kör Städning efter detta kan du kanske återvinna 125 istället för hela 175 som kan rengöras. Detta beror på att de senaste 2 filerna delar segment med filerna 1-3.  Rensning återställer inte de andra 50 GB lagringsutrymme eftersom dessa segment fortfarande används av filerna 3–5.
 

Exempel 2: Använd samma startpunkt som i exempel 1 och anta att fil 1 togs bort, sedan utfördes en snabbkopia på hela /backup-mappen (dvs. alla 5 filerna) och sedan borttagning av filerna 2–4. 

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

Siffran "Storlek GiB" för förkomposition kommer från (500–100)=400*2=800, vilket ger 500 för de 5 ursprungliga filerna, subtrahering av 100 för borttagning av fil 1 ger 400 GiB.  Därefter multipliceras 400 GiB med 2 på grund av snabbkopian på alla 4 återstående filer.

Observera att det utrymme som används efter komposition fortfarande är detsamma eftersom en filkopia bara lägger till en liten mängd utrymme, som består av metadatapekare till ursprungliga data. Utrymmesanvändningen har inte ändrats trots att fil 1 har tagits bort eftersom en "filesys clean start" inte har körts (för att initiera rensning). 
 

Efter städningen kommer vi att se:
 

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

Observera att även om 200 GB visades som möjligt rensades endast 25 GB. "Cleanable GiB" visades som 200 eftersom filstorleken "post-comp" för filerna 1 till 4 uppgick till 200 GB.  Endast "Fil 1" togs bort, vilket var 100 GB, men 75 GB användes fortfarande av de andra 4 filerna (på grund av deduplicering).  

Det kan tyckas konstigt, eftersom "Fil 2" till "Fil 4" också hade tagits bort, men kom ihåg att även om systemet kommer att visa "Fil 2" till "Fil 4" som borttagen, kunde de faktiska datasegmenten för dessa filer inte tas bort eftersom dessa filer hade snabbkopierats till en annan mapp.   Först när alla fastcopy-versioner också har tagits bort kan utrymmet återställas helt genom rensning.

Eftersom Cleanable GiB bara är en "uppskattning" och kanske inte är korrekt, kan den ibland återspegla stor eller samma storlek som den fysiska kapaciteten hos Data Domain.

Detta kan leda till förvirring om den schemalagda DDFS-rensningen ska köras eller om den ska köras manuellt om användningen av DDFS-utrymmet närmar sig 100 % på grund av att Cleanable GiB visas i närheten eller samma värde som "/data: post-comp".

För att få ett bättre och mer tillförlitligt sätt att uppskatta mängden diskutrymme som rensas skulle frigöras när den körs, från och med DDOS 7.7.x, är det nu möjligt att från CLI fastställa det faktiska "Total Cleanable-Space" nästa GC på den aktiva nivån kommer att kunna frigöras. Detta är en sammanfattning av CLI:
 

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

Processen gör samma sak som en vanlig GC och går igenom faserna 1 till 4, men hoppar över fas 5 (kopia), som är den som effektivt kopierar framåtcontainrar för att återta det döda diskutrymmet. Därför tar det lika lång tid som en vanlig GC tar att slutföra rensningsfaserna 1 till 4 för att returnera ett värde, så detta är inte något som ska köras regelbundet för att få en uppdaterad uppskattning, utan bara när det behövs. Med andra ord kommer "filesys cleanable-space calculate" att köra GC på den aktiva nivån och bara hoppa över den del där den frigör utrymme.

Processen kan övervakas på följande sätt:
 

# 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

När det är klart kan man komma åt det rengöringsbara mätresultatet:

# 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.

Så här i exempeltestet ovan, om DD GC ska köras nu, skulle det frigöra 94649698202 byte. Det är 88,1 GiB, medan uppskattningen som rapporterades av "df" i den DD i labbet som användes vid tidpunkten för beräkningen var 41,9 GiB. Naturligtvis, när ändringar görs i FS (nya säkerhetskopior, fler borttagningar, ögonblicksbilder som skapas och upphör att gälla, etc.) kommer beräkningen att gå igång.

Om det behövs, för att stoppa ovanstående process kan kommandot nedan användas:

# 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.

Observera att detta CLI endast gäller för DD Active-nivån. Det finns ingen motsvarande process för att beräkna vad som kan rensas för en DD-molnenhet, som har sin egen uppskattning, med förbehåll för samma osäkerheter som beskrivs ovan.