Data Domain: "Cleanable Size" ist eine Schätzung.

Es gibt oft Verwirrung über den Wert für "Cleanable GiB", der auf einem Data Domain-System angezeigt wird, und falsche Erwartungen hinsichtlich der Menge an Speicherplatz, die bei der Ausführung der Bereinigung wiederhergestellt wird.

Die angegebene Zahl für "Cleanable GiB" ist eine reine Schätzung und es ist aufgrund der technologischen Entscheidungen, die bei der Entwicklung des Data Domain-Dateisystems getroffen wurden, nicht möglich, einen genauen Wert dafür zu erhalten, wie viel Speicherplatz durch die Ausführung der Bereinigung wiederhergestellt wird.

Im Folgenden finden Sie eine prägnante Erklärung, warum die Schätzungen der zu reinigenden Fläche erheblich von der tatsächlich gewonnenen Fläche abweichen können. Es gibt jedoch andere Faktoren, die hier nicht berücksichtigt werden, wodurch die Schätzung und die Menge an Speicherplatz, die bei der Bereinigung wirklich frei wird, erheblich abweichen können
 

Wenn Daten vom Data Domain-System aufgenommen werden, wird der Wert nach der Komprimierung berechnet und als statische Daten für jede Datei gespeichert. Der Wert "Cleanable" ist einfach die Summe der Werte nach der Komprimierung für alle gelöschten Dateien seit dem letzten Ausführen der DD-Bereinigung bis zum Abschluss.
 

Der Wert für "Bereinigungsfähig" wird ungenau, wenn die Dateisegmente für gelöschte Dateien zur Deduplizierung von Daten in anderen Dateien verwendet wurden, die nicht gelöscht wurden. Solange eine einzelne Datei vorhanden ist, die sich auf ein vorhandenes eindeutiges Segment bezieht, werden diese Segmente beim DD-Bereinigungsprozess nicht für die Rückgewinnung berücksichtigt. Selbst wenn die Nachkomponierung einer Datei im Zähler "Bereinigbare GiB" hinzugefügt wurde, als ob alle ihre eindeutigen Segmente gelöscht werden sollten, werden einige (oder viele) möglicherweise nicht verwendet, weil sie von anderen Dateien wiederverwendet werden.
 

Es folgt ein ausführlicheres Beispiel, das diesen Effekt zeigt:

Angenommen, Sie haben 5 Dateien, die nacheinander zu einem Data Domain-System hinzugefügt werden, ohne dass zuvor andere Daten darauf gespeichert waren.

Da die ersten 100-GB-Dateien ausschließlich eindeutige Daten enthielten, beträgt das Komprimierungsverhältnis 1-fach (vorausgesetzt, die erste Datei hatte keine Redundanz in der Datei selbst). Die Dateien der 2. und 5. konnten anhand der Daten der 1. Datei und jeder der älteren Dateien dedupliziert werden, wenn sie hinzugefügt wurden, wobei jede Datei aufgrund der zunehmenden Anzahl von Dateien, für die sie dedupliziert werden musste, eine zunehmende Deduplizierung erhielt.

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

Beispiel 1. Status nach dem Löschen der ersten 3 Dateien aus /backup :
 

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

Wenn Sie danach die Bereinigung ausführen, können Sie möglicherweise 125 anstelle der vollen 175 bereinigungsfähigen Werte zurückgewinnen. Dies liegt daran, dass die letzten 2 Dateien Segmente mit den Dateien 1-3 teilen.  Die restlichen 50 GB Speicherplatz werden durch die Bereinigung nicht wiederhergestellt, da diese Segmente weiterhin von den Dateien 3 bis 5 verwendet werden.
 

Beispiel 2: Angenommen, Datei 1 wurde mit dem gleichen Ausgangspunkt wie in Beispiel 1 gelöscht, dann wird ein Fastcopy für den gesamten Ordner "/backup" durchgeführt (d. h. alle 5 Dateien) und dann werden die Dateien 2-4 gelöscht. 

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

Die Zahl "Größe in GiB" für die Vorkomprimierung ergibt sich aus (500-100) = 400*2=800, ergibt 500 für die 5 Originaldateien. Wenn Sie 100 für das Löschen von Datei 1 abziehen, erhalten Sie 400 GiB.  Als Nächstes 400 GiB multipliziert mit 2 aufgrund des Fastcopy auf allen 4 verbleibenden Dateien.

Beachten Sie, dass der verwendete Speicherplatz nach der Komprimierung immer noch derselbe ist, da eine Dateikopie nur eine winzige Menge Speicherplatz hinzufügt, der aus den Metadatenzeigern auf die Originaldaten besteht. Die Speicherplatznutzung hat sich trotz des Löschens von Datei 1 nicht geändert, da kein "filesys clean start" ausgeführt wurde (um die Bereinigung zu initiieren). 
 

Nach der Reinigung werden wir sehen:
 

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

Beachten Sie, dass zwar 200 GB als bereinigungsfähig angezeigt wurden, aber nur 25 GB tatsächlich bereinigt wurden. Die "Cleanable GiB" wurde mit 200 angegeben, da die Dateigröße nach der Komprimierung der Dateien 1 bis 4 insgesamt 200 GB betrug.  Es wurde nur "Datei 1" entfernt, die 100 GB groß war, aber 75 GB von den anderen 4 Dateien noch verwendet wurden (aufgrund von Deduplizierung).  

Das mag seltsam erscheinen, da "Datei 2" bis "Datei 4" ebenfalls gelöscht wurden, aber denken Sie daran, dass das System zwar "Datei 2" bis "Datei 4" als entfernt anzeigt, die eigentlichen Datensegmente für diese Dateien jedoch nicht entfernt werden konnten, da diese Dateien per Fastcopy in einen anderen Ordner kopiert wurden.   Erst nachdem alle Fastcopy-Versionen ebenfalls entfernt wurden, kann der Speicherplatz durch Bereinigung vollständig wiederhergestellt werden.

Da es sich bei den bereinigungsfähigen GiB nur um eine "Schätzung" handelt, die möglicherweise nicht genau ist, kann sie manchmal auch groß oder gleich groß wie die physische Kapazität von Data Domain sein.

Dies kann zu Verwirrung führen, ob die geplante DDFS-Bereinigung ausgeführt werden soll oder ob sie manuell ausgeführt werden soll, wenn die DDFS-Speicherplatzauslastung nahezu 100 % erreicht, weil "Cleanable GiB" in der Nähe oder denselben Wert wie "/data: post-comp" anzeigt.

Um eine bessere und zuverlässigere Methode zur Schätzung der Menge an Speicherplatz zu haben, die bereinigt bei der Ausführung zurückgewinnen würde, ist es ab DDOS 7.7.x jetzt möglich, über die CLI den tatsächlichen "Total Cleanable-Space" zu bestimmen, den der nächste GC auf dem aktiven Tier zurückgewinnen kann. Dies ist eine Zusammenfassung der CLI:
 

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

Der Prozess verfährt dasselbe wie ein regulärer GC, durchläuft die Phasen 1 bis 4, überspringt jedoch Phase 5 (Kopie), die Container effektiv weiterkopiert, um den inaktiven Speicherplatz zurückzugewinnen. Daher dauert es so lange, wie ein regulärer GC benötigt, um die Bereinigungsphasen 1 bis 4 abzuschließen, um einen Wert zurückzugeben, sodass dies nicht regelmäßig ausgeführt werden sollte, um eine aktualisierte Schätzung zu erhalten, sondern nur, wenn dies erforderlich ist. Mit anderen Worten, "filesys cleanable-space calculate" führt GC im aktiven Tier aus und überspringt einfach den Teil, in dem Speicherplatz zurückgewonnen wird.

Der Prozess kann wie folgt überwacht werden:
 

# 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

Nach Abschluss kann man auf das reinigbare Messergebnis zugreifen:

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

Wenn also hier im obigen Beispieltest die DD GC jetzt ausgeführt werden soll, würde sie 94649698202 Byte freigeben. Das sind 88,1 GiB, während zum Zeitpunkt der Berechnung die von "df" gemeldete Schätzung im verwendeten Labor DD bei 41,9 GiB lag. Wenn Änderungen am Dateisystem vorgenommen werden (neue Backups, weitere Löschvorgänge, erstellte und abgelaufene Snapshots usw.), wird die Berechnung natürlich falsch durchgeführt.

Falls erforderlich, kann der folgende Befehl verwendet werden, um den obigen Prozess zu beenden:

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

Beachten Sie, dass diese CLI nur für den DD Active-Tier gilt. Es gibt keinen gleichwertigen Prozess zur Berechnung der bereinigungsfähigen Daten für eine DD-Cloudeinheit, die über eine eigene Schätzung verfügt, die denselben Unsicherheiten wie oben beschrieben unterliegt.