Data Domain: Die geplante Bereinigung kann nicht gestartet werden und es wird die Warnung "EVT-GC-00002: Die geplante Dateisystembereinigung kann nicht gestartet werden
Summary: Die Ausführung der DataDomain-Bereinigung (GC) ist für bestimmte Tage und Zeiten geplant. Wenn in neueren DDOS-Versionen ein solcher Zeitplan vorhanden ist und der Bereinigungsprozess aus irgendeinem Grund nicht gestartet werden kann, wird dies vom Systemüberwachungs-Daemon bemerkt, der eine Warnmeldung ausgibt. ...
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
Die DataDomain-Bereinigung (automatische Speicherbereinigung, GC) wird für die Ausführung an bestimmten Tagen und zu bestimmten Zeiten geplant. Wenn in DDOS 6.0.x und neueren Versionen ein solcher Zeitplan vorhanden ist und der Bereinigungsprozess aus irgendeinem Grund nicht gestartet werden kann, wird dies vom Systemüberwachungs-Daemon bemerkt und löst schließlich eine Warnmeldung wie die folgende aus:
# alerts show current # alerts show current Id Post Time Severity Class Object Message ----- ------------------------ -------- ----------- --------- ----------------------------------------------------------------------------------------- m0-11 Tue Jun 27 16:32:03 2017 WARNING Filesystem EVT-GC-00002: Unable to start scheduled file system cleaning on Tue Jun 27 16:04:00 2017. ----- ------------------------ -------- ----------- --------- -----------------------------------------------------------------------------------------
Außerdem wird eine Warnungs-ASUP mit Details wie den folgenden gesendet:
Hostname: dd-6800 Location: Lab4_Row_M System SerialNo: APMxxxxxxxxxxxxxx Chassis SerialNo: FCxxxxxxxxxxxxxxx ModelNo: DD6800 Version: 6.0.0.1 Time: Tue Jun 27 16:15:02 2017 Alert Id: m0-11 Event Id: EVT-GC-00002 Event Message: Unable to start scheduled file system cleaning on Tue Jun 27 16:04:00 2017. Event Description: Cleaning has not started as scheduled. Space for deleted files will not be reclaimed until cleaning completes. This may impact the ability to backup. Recommended Action: Determine the reason why cleaning did not start. Manually start cleaning if free space needs to be reclaimed before the next scheduled cleaning. If problem persists, contact your contracted support provider or visit us online at https://support.emc.com.
Cause
Die Warnmeldung informiert nur darüber, dass ein Bereinigungsprozess geplant ist, der zum geplanten Zeitpunkt nicht gestartet werden konnte. Dafür gibt es mehrere mögliche Gründe, von denen die meisten kein Hinweis auf ein Problem sind. Die Warnmeldung kann unter anderem aus folgenden Gründen ausgelöst werden:
Ein weiterer Grund, warum wir in der Vergangenheit, wenn auch sehr selten, gesehen haben, dass GC übersprungen wird, ist eine Inkonsistenz für den Zeitplan für die Bereinigung in der Registrierung. Beispielsweise zeigen sowohl die Registrierung als auch die CLI an, dass GC sonntags um 06:00 Uhr Ortszeit ausgeführt werden soll:
Ein anderer Registrierungsschlüssel (collection.1.crontab.expunge), der vom Prozessplaner "crontab" zum Starten der konfigurierten Jobs verwendet wird, ist jedoch falsch, z. B.:
- DD GC wurde bereits ausgeführt, als der geplante Bereinigungsprozess gestartet werden musste. Da zu einem gegebenen Zeitpunkt nur ein GC-Prozess ausgeführt werden kann und der Versuch eines solchen Prozesses einen laufenden GC nicht verhindert, wurde der geplante Prozess übersprungen und somit die Warnmeldung
- Aktionen, die mit GC nicht kompatibel sind, wie z. B. das Ausführen einer Datenverschiebung (FMIG) vom Speicher-Tier "Aktiv" in "Archiv" oder das Ausführen einer Bereinigung des Cloud Tier zu dem Zeitpunkt, zu dem die GC des aktiven Tier beginnen sollte
- Eine frühere Änderung der Systemzeitzone könnte dazu geführt haben, dass der interne "cron"-Daemon, der für geplante Aufgaben zuständig ist, weiterhin in der alten Zeitzone statt in der neuen Zeitzone ausgeführt wird. Je nach vorheriger und aktueller Zeitzone kann DD GC möglicherweise mehrere Stunden früher oder später als erwartet ausgeführt werden, wodurch die Warnmeldung für den übersprungenen GC ausgegeben wird. Sie können die Wissensdatenbank Data Domain überprüfen: So ändern Sie Datum/Uhrzeit und/oder Zeitzone auf einem Data Domain Restorer (DDR) für weitere Details zu Zeitzonenänderungen in einer DD
- Intern wird die DD-Bereinigung gestartet, indem ein Job für den Befehl "filesys clean start" an den internen "sms"-Daemon gesendet wird. Wenn "sms" nicht reagiert oder das FS nicht rechtzeitig auf "sms" antwortet, wird GC nicht gestartet und übersprungen. Sie können das Protokoll "sms.info" auf übereinstimmende Einträge wie diese überprüfen, die darauf hinweisen würden, dass eine Bereinigung versucht wurde, der Job jedoch nicht gestartet werden konnte:
28.02. 12:00:26.495 (TID 0xa79c040): Auftrag abgeschlossen: 3278752 für den Betrieb: sms_filesys_clean_start, Dauer: 25067 ms, Status: Das Dateisystem reagiert nicht.
- Das Gleiche wie oben, aber aufgrund von "Time backward jump" wird der Dienst von cron nicht mit der neuen Zeiteinstellung
synchronisiert. Wir können so etwas wie das Folgende auf ASUP finden:
config.snmp.trapinfo.17 = Dateisystem ist aufgrund eines kritischen Zustands deaktiviert. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=Systemzeit rückwärts gesprungen config.snmp.trapinfo.19 = Die geplante Dateisystembereinigung kann am Tue Nov 15 06:00:00 2022 nicht gestartet werden.
- Wenn das FS ausgefallen ist, nicht reagiert oder zu diesem Zeitpunkt ein HA-Failover stattfand oder die DD neu gestartet wurde oder ausgefallen ist, wurde GC möglicherweise ebenfalls übersprungen
Ein weiterer Grund, warum wir in der Vergangenheit, wenn auch sehr selten, gesehen haben, dass GC übersprungen wird, ist eine Inkonsistenz für den Zeitplan für die Bereinigung in der Registrierung. Beispielsweise zeigen sowohl die Registrierung als auch die CLI an, dass GC sonntags um 06:00 Uhr Ortszeit ausgeführt werden soll:
# reg show collection.1.expunge.schedule
collection.1.expunge.schedule.days = Sun
collection.1.expunge.schedule.time = 0600
# filesys clean show config
Filesystem Cleaning Configuration
---------------------------------
50 Percent Throttle
Filesystem cleaning is scheduled to run "Sun" at "0600".
Ein anderer Registrierungsschlüssel (collection.1.crontab.expunge), der vom Prozessplaner "crontab" zum Starten der konfigurierten Jobs verwendet wird, ist jedoch falsch, z. B.:
# reg show collection.1.crontab.expunge collection.1.crontab.expunge = 00 6 * * 2 root /ddr/bin/ddsh -s filesys clean start nowait scheduled
Der obige Registrierungsschlüssel gibt an, dass die geplante Bereinigung dienstags um 06:00 Uhr Ortszeit (2 in der fünften "crontab"-Jobspezifikation) statt sonntags (0) gestartet werden soll.
Resolution
Sie können die Warnmeldung jederzeit löschen, dies löst jedoch weder das zugrunde liegende Problem, noch führt dies dazu, dass die Bereinigung sofort gestartet wird. Je nach Ursache für den übersprungenen GC-Zyklus ist der Ansatz unterschiedlich und dieser Wissensdatenbank-Artikel wird nicht weiter darauf eingehen. Lesen Sie die Wissensdatenbank-Artikel zu Dell EMC DataDomain, um Hilfe zu erhalten, oder wenden Sie sich an den von Ihnen beauftragten Supportanbieter, falls dies nicht der Fall ist.
Im Falle von 'Time backward jump' können wir einfach noch einmal überprüfen, ob die reg config mit dem Zeitplan 'filesys clean' übereinstimmt und den Cron-Service neu starten:
* Hinweis: Für den Befehl ist eine Bash-Modus-Konsole erforderlich, falls Sie einen neuen SR öffnen, um Hilfe vom Data Domain-Support zu erhalten.
Vergewissern Sie sich anschließend, dass der Registrierungsschlüssel, der angibt, dass die Bereinigung für den falschen Tag geplant werden soll, aktualisiert wurde:
Im Falle von 'Time backward jump' können wir einfach noch einmal überprüfen, ob die reg config mit dem Zeitplan 'filesys clean' übereinstimmt und den Cron-Service neu starten:
* Hinweis: Für den Befehl ist eine Bash-Modus-Konsole erforderlich, falls Sie einen neuen SR öffnen, um Hilfe vom Data Domain-Support zu erhalten.
1 | double-check job configuration # filesys clean show schedule Filesystem cleaning is scheduled to run "Wed" at "1600". # reg show collection.1.crontab.expunge collection.1.crontab.expunge = 0 16 * * 3 root /ddr/bin/ddsh -s filesys clean start nowait scheduled 2 | set a new schedule if needed # filesys clean set schedule Wed 1600 3 | Restart the cron service [you can use one of them] # /etc/init.d/crond restart or # systemctl restart crond.service
Für das Problem mit den inkonsistenten Registrierungseinträgen besteht die Korrektur darin, den richtigen Bereinigungsplan entweder über die CLI oder die CLI zwangsweise festzulegen. Um mit dem Beispiel fortzufahren, müsste der Administrator den Bereinigungsplan auf Sonntage um 06:00 Uhr setzen, auch wenn "filesys clean show schedule" dies bereits meldet:
# filesys clean show schedule Filesystem cleaning is scheduled to run "Sun" at "0600". # filesys clean set schedule Sun 0600 Filesystem cleaning is scheduled to run "Sun" at "0600". # filesys clean show schedule Filesystem cleaning is scheduled to run "Sun" at "0600".
Vergewissern Sie sich anschließend, dass der Registrierungsschlüssel, der angibt, dass die Bereinigung für den falschen Tag geplant werden soll, aktualisiert wurde:
# reg show collection.1.crontab.expunge collection.1.crontab.expunge = 0 6 * * 0 root /ddr/bin/ddsh -s filesys clean start nowait scheduled
Affected Products
Data Domain, DD OS 6.0Article Properties
Article Number: 000052147
Article Type: Solution
Last Modified: 17 Jul 2023
Version: 4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.