Dateisysteme
Schnellzugriff:
- Home (/G/home/$USER) für Programmtexte, Endergebnisse mit Backup
- globales Arbeitsverzeichnis (/G/scratch/$USER) für große Arbeitsdaten, Zwischenergebnisse (work)
- Job-Scratch ($TMPDIR) für temporäre Daten eines Rechenjobs (scratch)
- Job-Arbeitsverzeichnis ($RRZ_WORKDIR) für schnelles, lokales Arbeiten auf einer Kopie des Arbeitsverzeichnisses
Den Benutzern ($USER als Platzhalter für die Kennung) stehen verschiedene Verzeichnisse zur Verfügung. Ein jedes hat seinen Einsatzzweck. Bitte beachten Sie insbesondere die Abschnitte zu $TMPDIR und $RRZ_WORKDIR und nutzen diese auch, damit die Ressourcen des Clusters sinnvoll genutzt werden!
Heimatdateisystem /G/home/$USER (Home, 6,3 TiB gesamt) oder /G/home2/$USER
In der Endphase des Betriebes des Clusters bekommen bestimmte Nutzer ihr Heimatverzeichnis unter /G/home2, nicht /G/home. Man sollte immer die Variable $HOME verwenden, um das richtige Verzeichnis zu erhalten!
Hier gilt ein Quota von 200GB Soft- und 250GB Hardlimit. Daten im Home werden täglich im Backup-System gesichert. Dieses Dateisystem ist global auf allen Knoten verfügbar. Hier haben Programme/Skripte sowie moderate Log-Dateien ihren Platz. Primär liegen hier Dinge, die der Nutzer selbst berarbeitet, im Gegensatz zu den automatisch reproduzierbaren Ergebnissen von Rechenjobs.
Ausgabedaten / Analyseergebnisse können hier zwischengelagert werden und genießen auch gewisse Sicherheit durch das Backup. Langfristig sollten Nutzer aber ihre Ergebnisse auf eigene Systeme kopieren (per ssh bzw. scp). Es sollte vermieden werden, intensive Dateioperationen von Rechenjobs unter /G/home auszuführen!
Globales Arbeitsverzeichnis /G/scratch/$USER (Scratch, 5,4 TiB gesamt) der /G/scratch2/$USER
In der Endphase des Betriebes des Clusters bekommen bestimmte Nutzer ihr Arbeitsvrzeichnis unter /G/scratch2, nicht /G/scratch. Man sollte immer die Ausgabe von
/G/home/rrz/bin/rrz-globalscratch
verwenden, um das richtige Verzeichnis zu erhalten!
Dieses für alle Knoten verfügbare Verzeichnis ist für Vorbereitung und Ergebnisse von Rechenjobs gedacht. Einfache Dateioperationen (Einlesen von Eingabedaten oder Produktion von Ausgabedaten als kontinuierlicher Strom bzw. in großen Blöcken) können auch von den Jobs direkt hier durchgeführt werden. Aufwändigere Operationen mit starker Beanspruchung (klassisch als „scratch I/O“ bezeichnet) sind in der Regel auf lokalem Speicherplatz besser aufgehoben, da sich die Zugriffe verschiedener Knoten sonst gegenseitig behindern und das Dateisystem für alle Nutzer ausbremsen.
Es gibt hier kein Quota und kein Backup. Nutzer, die längerfristig große Datenmengen auf /G/scratch belegt haben werden aufgefordert, alte Daten zu löschen. Wichtige Ergebnisse sollten zeitnah auf eigene Dateisysteme kopiert werden (im Rahmen der Quota-Grenze auch zwischenzeitlich im Home). Bei akuter Überfüllung von /G/scratch können Daten ohne Vorwarnung gelöscht werden, um den Betrieb sicherzustellen!
Lokales Job-Scratchverzeichnis ($TMPDIR)
Für intensive Dateioperationen (im Zweifelsfall für alle transienten Daten des Jobs) wird für jeden Job automatisch ein temporäres Verzeichnis angelegt. Nach Beendigung des Jobs wird dieses auch automatisch wieder gelöscht. Im Normalfall liegt es auf der lokalen Festplatte des ersten Knotens für den Job und ist für alle anderen Knoten transparent erreichbar. Es ist sehr wichtig, dass temporäre Daten, wie sie z.B. Gaussian und Schrödinger-Anwendungen erzeugen, bevorzugt auf lokalen Dateisystemen liegen, um den Cluster effizient zu nutzen.
Die Shell-Variable $TMPDIR enthält den Pfad des erzeugten und für den Job spezifischen Verzeichnisses. Man erhält sie durch zwei Zeilen im Job-Script, für Bourne Shell (sh, bash):
source /G/home/rrz/lib/modules.sh module load rrz/tmpdir
und für C-Shell (csh, tcsh):
source /G/home/rrz/lib/modules.csh module load rrz/tmpdir
Danach kann der durch $TMPDIR angegebene Ort für temporäre Daten genutzt werden. Es werden automatisch Variablen gesetzt, die bestimmte Programme dazu veranlassen, temporäre Daten dort zu speichern. Dazu gehören $GAUSS_SCRDIR (Gaussian) und $SCHRODINGER_TMPDIR. Insbesondere die Einstellung für Gaussian ist wegen der intensiv genutzten .rwf-Dateien wichtig. Falls man weiß, dass mehr als 100 GiB temporärer Speicherplatz benötigt werden, kann mittels der Variable $RRZ_TMPDIR_GLOBAL erzwungen werden, dass $TMPDIR auf /G/scratch eingerichtet wird. Das sollte aber die Ausnahme sein. Der qsub-Aufruf sieht dann z.B. so aus:
qsub -v RRZ_TMPDIR_GLOBAL=1 -q c8 jobscript.sh
Das zu einem aktiven eigenen Job gehörige temporäre Arbeitsverzeichnis kann vom Nutzer unter Kenntnis der Job-ID mit dem Befehl
/G/home/rrz/bin/rrz-job-get-tmpdir $job_id
erfragt werden. Solange der Job läuft, is dieses Verzeichnis auch vom Login-Knoten aus einsehbar. Da es mit Beendigung (auch Abbruch) des Jobs notwendigerweise gelöscht wird, sollte der Job so gestaltet sein, dass er notwendige Zwischenergebnisse bzw. Restart-Files an permanenter Stelle hinterlässt. Auch wenn dieser Aspekt unbequem erscheint, sollte unbedingt mit dem unabhängigen $TMPDIR gearbeitet werden, damit der gesamte Cluster sinnvoll ausgelastet ist.
Bitte beachten Sie: Der alte Mechanismus, per Variable PBS_LOCAL_SCRATCH ein lokales Arbeitsverzeichnis anzufordern, ist nun überflüssig und wird in Zukunft, sobald gesichert ist, dass kein Job diesen mehr braucht, deaktiviert.
Job-Arbeitsverzeichnis ($RRZ_WORKDIR)
Manche Programme sind schwer vom unkontrollierten Schreiben im aktuellen Arbeitsverzeichnis (üblicherweise gleich $PBS_O_WORKDIR, das Verzeichnis, in dem qsub aufgerufen wurde) abzubringen. Daher gibt es einen allgemeinen Mechanismus, der vor Start des Job-Skriptes das Arbeitsverzeichnis ($PBS_O_WORKDIR) in ein Job-spezfisches Verzeichnis kopiert, das normalerweise auf der lokalen Festplatte des ersten Knotens des Jobs liegt. Der technische Vorteil ist analog zu $TMPDIR: kein gegenseitiges Ausbremsen von Jobs durch I/O.
Nach Beendigung des Job-Skriptes --- auch, wenn es mit einem Programmfehler abbricht --- werden die Neuerungen aus $RRZ_WORKDIR zum ursprünglichen Arbeitsverzeichnis $PBS_O_WORKDIR übertragen. Dies beinhaltet Schreiben von geänderten Daten, nicht aber das Löschen von Dateien, die in $RRZ_WORKDIR nicht mehr existieren. Dies ist eine Vorsichtsmaßnahme, um ungewollten Datenverlust durch Programmierfehler (in den relevanten Prolog-/Epilog-Skripten) zu vermeiden.
Die Variable zur Aktivierung des Mechanismus heißt $RRZ_TMP_WORKDIR und kann wie ähnliche Variablen auch in der qsub-Kommandozeile oder im Job-Skript angegeben werden. Nutzung im Jobskript folgt diesem Beispiel:
#!/bin/bash #PBS -v RRZ_TMP_WORKDIR=1 # Stellt $TMPDIR und $RRZ_WORKDIR zur Verfügung. source /G/home/rrz/lib/modules.sh module load rrz/environment # Wechsel ins lokale Arbeitsverzeichnis. cd $RRZ_WORKDIR # Job-Skript wie gehabt, als wäre man in $PBS_O_WORKDIR. echo "I am in $PWD, which will sync to $PBS_O_WORKDIR." touch been-there
Für Batch-Jobs mit RRZ_TMP_WORKDIR=1 liegt das Verzeichnis $RRZ_WORKDIR an der Seite des Job-spezifischen $TMPDIR. Daher hat die Variable RRZ_TMPDIR_GLOBAL Einfluss darauf, ob es auf der lokalen Festplatte eines Knotens oder auf /G/scratch liegt. Dies legt $TMPDIR und $RRZ_WORKDIR auf /G/scratch an:
qsub -v RRZ_TMP_WORKDIR=1,RRZ_TMPDIR_GLOBAL=1 -q c8 jobscript.sh
(analog Aufnahme der zweiten Variable im Kopfteil des Skriptes). Dies sollte aber nur in Betracht gezogen werden, wenn die Datenmenge auf der lokalen Festplatte nicht genug Platz hätte.
Für Batch-Jobs ohne RRZ_TMP_WORKDIR=1 (z.B. explizit RRZ_TMP_WORKDIR=0) ist das von rrz/environment gesetzte $RRZ_WORKDIR identisch zu $PBS_O_WORKDIR und es findet keine Kopie statt.
Insbesondere für Rechenaufträge mit längerer Laufzeit bietet sich der Zugriff auf das Job-Arbeitsverzeichnis vom Login-Knoten aus an. So kann man sich Archive für Restarts anlegen oder auch einfach den Fortschritt der Rechnung beobachten, wie es mit einem Arbeitsverzeichnis in /G/home oder /G/scratch auch ginge.
Als Ausgabe des Kommandos
/G/home/rrz/bin/rrz-job-get-workdir
erhält man den Pfad des Job-Arbeitsverzeichnisses. In einer normalen Shell-Sitzung außerhalb des Batchsystems gibt dies "." zurück, was sich immer auf das aktuelle Arbeitsverzeichnis in der Shell bezieht.