Datadomene: Rengjørbar størrelse er et estimat

Det oppstår ofte forvirring om verdien "Cleanable GiB" som presenteres på et Data Domain-system, og feilaktige forventninger om hvor mye plass som vil bli gjenopprettet ved rengjøring.

Det oppgitte "Cleanable GiB"-tallet er et rent estimat, og det er ikke mulig å få en nøyaktig verdi for hvor mye plass som vil bli gjenvunnet ved å kjøre rengjøring, på grunn av de teknologiske valgene som ble gjort ved utviklingen av Data Domain Filesystem.

Følgende er en kortfattet forklaring på hvorfor estimater av rengjørbar plass kan variere vesentlig fra den faktiske plassen som er gjenopprettet. Det er imidlertid andre faktorer som ikke er redegjort for her, noe som kan gjøre estimatet og mengden diskplass som virkelig frigjøres når du kjører rent, for å avvike vesentlig
 

Når data tas inn av Data Domain-systemet, beregnes og lagres verdien etter komprimering som statiske data for hver fil. "Cleanable"-verdien er ganske enkelt summen av verdien etter komprimering for alle slettede filer siden forrige gang DD clean ble kjørt til ferdigstillelse.
 

Verdien for Ryddbar blir unøyaktig hvis filsegmentene for slettede filer har blitt brukt til å deduplisere data i andre filer som ikke er slettet. Så lenge det er en enkelt fil som refererer til et eksisterende, unikt segment, vil ikke DD-renseprosessen vurdere disse segmentene for å bli gjenvunnet. Så selv om en fils etterkomp ble lagt til i "Cleanable GiB"-telleren som om alle de unike segmentene var i ferd med å bli avhendet, kan det hende at noen (eller mange) ikke er det på grunn av gjenbruk av andre filer.
 

Et mer detaljert eksempel som viser denne effekten følger:

Anta at du har 5 filer, lagt til en etter en til et Data Domain-system, uten andre data tidligere.

Siden de første 100 GB-filene inneholdt alle unike data, er komprimeringsforholdet 1x (forutsatt at den første filen ikke hadde noen redundans i selve filen). 2.-5. filene var i stand til å duplisere mot 1. fils data og hver av de eldre filene etter hvert som de ble lagt til, hver av dem fikk økende deduplisering på grunn av de økende filene som de-duplisering skulle dedupliseres.

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

Eksempel 1. Status etter sletting av de første 3 filene fra / backup:
 

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

Hvis du kjører rengjøring etter dette kan du være i stand til å gjenvinne 125 i stedet for hele 175 rensbare. Dette skyldes det faktum at de siste 2 filene deler segmenter med filer 1-3.  Opprydding vil ikke gjenopprette de andre 50 GB plass fordi disse segmentene fortsatt er i bruk av filer 3-5.
 

Eksempel 2: Ved å bruke samme utgangspunkt som med eksempel 1, anta at fil 1 ble slettet, deretter en fastcopy utført på hele /backup-mappen (dvs. alle 5 filene), deretter sletting av filene 2-4. 

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

"Size GiB" -tallet for pre-comp kommer fra (500-100) = 400 * 2 = 800, noe som gir 500 for de 5 originale filene, fratrekk av 100 for å slette fil 1 gir 400 GiB.  Deretter multiplisert 400 GiB med 2 på grunn av hurtigkopien på alle 4 gjenværende filer.

Merk at post-comp-plassen som brukes, fortsatt er den samme fordi en filkopi bare legger til en liten mengde plass, bestående av metadatapekerne til de opprinnelige dataene. Plassbruken er ikke endret til tross for sletting av fil 1 fordi en "filesys clean start" ikke har blitt kjørt (for å starte opprydding). 
 

Etter rengjøringen vil vi se:
 

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

Merk at selv om 200 GB ble vist rengjørbar, ble bare 25 GB faktisk rengjort. "Cleanable GiB" ble vist som 200 fordi "post-comp"-filstørrelsen på fil 1 til 4 ble opptil 200 GB.  Bare "File 1" ble fjernet som var 100GB, men 75GB som fortsatt var i bruk av de andre 4 filene (på grunn av de-duplisering).  

Det kan virke rart, siden "File 2" til "File 4" også hadde blitt slettet, men husk at selv om systemet vil vise "File 2" til "File 4" som fjernet, kunne de faktiske datasegmentene for disse filene ikke fjernes fordi disse filene hadde blitt hurtigkopiert til en annen mappe.   Først etter at alle fastcopy-versjoner også er fjernet, kan plassen gjenopprettes fullstendig ved rengjøring.

Siden rengjørbar GiB bare er et "estimat" og kanskje ikke er nøyaktig, selv noen ganger kan det gjenspeile stor eller samme størrelse som den fysiske kapasiteten til Data Domain.

Dette kan føre til forvirring om den planlagte DDFS-rengjøringen skal kjøres eller kjøres manuelt hvis bruken av DDFS-plassen nærmer seg 100 % på grunn av at rengjørbar GiB viser nærliggende eller samme verdi som "/data: post-comp".

For å få en bedre og mer pålitelig måte å estimere hvor mye diskplass ren ville gjenvinne når du kjører, starter fra DDOS 7.7.x er det nå mulig å fastslå fra CLI den faktiske "Total Cleanable-Space" neste GC på Active-nivået vil kunne gjenvinne. Dette er et sammendrag av CLI:
 

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

Prosessen vil gjøre det samme som en vanlig GC, gå gjennom fase 1 til 4, men hoppe over fase 5 (kopi), som er den som effektivt vil kopiere fremoverbeholdere for å gjenvinne den døde diskplassen. Som sådan vil det ta så lang tid som en vanlig GC tar å fullføre rene faser 1 til 4 for å returnere en verdi, så dette er ikke noe som skal kjøres regelmessig for å ha et oppdatert estimat, men bare når det trengs. Med andre ord, "filesys cleanable-space calculate" vil kjøre GC i Active-nivået bare hoppe over den delen der den gjenvinner plass.

Prosessen kan overvåkes slik:
 

# 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 er fullført, kan man få tilgang til det rengjørbare måleresultatet:

# 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å her i eksempeltesten ovenfor, hvis DD GC skal kjøres nå, vil det frigjøre 94649698202 byte. Det er 88,1 GiB, mens på tidspunktet for beregningen var estimatet rapportert av "df" i laboratoriet DD brukte 41,9 GiB. Når det gjøres endringer i FS (nye sikkerhetskopier, flere slettinger, øyeblikksbilder blir opprettet og utløpt, etc.), vil beregningen selvfølgelig gå av.

Hvis nødvendig, for å stoppe prosessen nedenfor kommandoen kan brukes:

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

Vær oppmerksom på at denne CLI-en bare gjelder for DD Active-nivået. Det er ingen tilsvarende prosess for å beregne rens for en DD-skyenhet, som har sitt eget estimat, underlagt de samme usikkerhetene som beskrevet ovenfor.