Für Nutzerdaten stehen die folgenden Dateisysteme zur Verfügung:

Seit Oktober 2019 unterscheiden sich die global verfügbaren Filesysteme nicht mehr in Bezug auf Durchsatz und Latenz, weil sie sich denselben großen Pool aus NVMe-SSDs teilen.

Trotzdem unterteilen interne Optimierungen die Filesysteme in zwei „Klassen“: geringe bis moderate I/O-Last und Hohe I/O-Last .

___________________________________________________________________________

Hinweis

Wegen des zu großen Umfangs für Snapshots und Backups: Nutzen Sie /home, /work/groups und /work/projects nicht für laufende Jobs mit hoher I/O-Last (z.B. sehr viele kleine Dateien), sondern nur für das Speichern der Endergebnisse!

Sicherung/Backup

Für diese Klasse von Filesystemen mit geringer I/O-Rate (Zahl und Größe von Dateien) gibt es folgende Sicherungsmechanismen:

• tägliche Sicherungen auf Magnetband
  Diese Sicherungen dienen hauptsächlich zum Schutz gegen katastrophale Ausfälle/Schäden am Filesystem, und stehen nicht direkt für die individuelle Wiederherstellung versehentlich gelöschter Daten zur Verfügung
• Snapshots
  Explizit für die eigene Wiederherstellung durch die Nutzenden sind die „Snapshots“ gedacht, die das GPFS-Filesystem regelmäßig erstellt (siehe „Technologie“ weiter unten). Aus dem versteckten Verzeichnis „.snapshots/“ in jedem Unterverzeichnis kann man sich jederzeit ältere oder versehentlich gelöschte Dateien heraus- und wieder an den Originalverzeichnis zurückkopieren (siehe weiter unten „Technologie“).

Nutzen Sie keine Verzeichnisse dieser Filesysteme als Arbeitsverzeichnis für laufende Jobs!

Das Homedirectory sollte für alle Daten verwendet werden, die dauerhaft wichtig sind.

Jeder Nutzer bzw. jede Nutzerin darf dort nur eine begrenzte Datenmenge ablegen (siehe „quota“ oben). Nach Absprache kann die Quota im begründeten Einzelfall erhöht werden.

Das Verzeichnis /home/$USER („Home“) wird gleichzeitig mit dem Nutzerkonto erzeugt. Man kann es wie üblich mit der Umgebungsvariable $HOME referenzieren.

Auf Anfrage können größere Gruppen (Institute) ein Gruppenverzeichnis erhalten, um dort statische Input-Daten bzw. gemeinsam genutzte Programme abzulegen.

Ebenso können Projekte mit mehr als nur ein paar Mitgliedern ein Projektverzeichnis für dieselben Zwecke erhalten.

___________________________________________________________________________

Sicherung/Backup

KEINE!

Diese Klasse von Filesystemen ist ausschließlich auf hohe I/O-Last und hohen Durchsatz für die Jobs/Anwendungen hin optimiert.

Da hier außerdem die Änderungsrate pro Zeit sehr hoch ist, würden herkömmliche Sicherungsmechanismen zu einer „Datenexplosion“ im (teuren) Magnetband-Backup führen. Aus demselben Grund bergen Snapshots die Gefahr, das FIlesystem sehr schnell vollaufen zu lassen.

Es gibt keinerlei Sicherung auf den folgenden Filesystemen – was Sie dort löschen, ist für immer weg und kann auch durch die Administratoren nicht wiederhergestellt werden!

Hier gibt es für alle User-Accounts Plattenplatz in (nahezu) unbegrenzter Menge, aber nur für begrenzte Zeit: die hier abgelegten Daten werden ohne vorherige Warnung nach 8 Wochen gelöscht, sofern sie so lange nicht geschrieben wurden (automatische Lösch-Policy).
Ein lesender Zugriff auf Dateien reicht nicht, um die Löschung zu verhindern, da das „last access date“ aus Performancegründen nicht zeitnah/zuverlässig aktualisiert wird.

Das Verzeichnis /work/scratch/$USER („Scratch“) wird gleichzeitig mit dem Nutzerkonto erzeugt. Man kann es in (Job-) Scripts über die Umgebungsvariable $HPC_SCRATCH referenzieren.

___________________________________________________________________________

Alle oben aufgeführten globalen, also cluster-weit verfügbaren Dateisysteme sind mittels IBMs Storage Scale (früher General Parallel File System) aufgesetzt. Dieses kommerzielle, lizenzpflichtige Produkt erlaubt es, große Plattenverbünde an Tausende von Knoten über Infiniband freizugeben.

Die Schreib-/Lesevorgänge solch enormer Knotenzahlen zu prüfen und zu verarbeiten dauert natürlich etwas länger, als auf lokale Platten zuzugreifen. Außerdem arbeiten alle laufenden Jobs und alle angemeldeten Benutzer zeitgleich auf dem gemeinsamen Filesystem.

Daher kann es auf dem IBMs Storage Scale immer mal wieder zu kurzen „Gedenksekunden“ kommen, wenn man „ls -l“ o.ä. ausführt. Dieses Verhalten ist normal und dem Prinzip „geteiltes, gemeinsames, überall verfügbares Filesystem“ geschuldet.

Für Ordner auf den Filesystemen mit geringem Turnover bzw. I/O-Volumen wird durch IBM Storage Scale In regelmäßigen Abständen ein Abbild der Inhalte eingefroren („Snapshots“). So ist es möglich, selbst und ohne Administratorhilfe auf ältere Versionen Ihrer Daten zurückzugreifen. Die Snapshots sind in dem unsichtbaren Verzeichnis .snapshots gespeichert (das auch mit 'ls -la' nicht angezeigt wird). Sie können trotzdem mit „cd .snapshots“ in dieses Verzeichnis wechseln (<TAB>-completion funktioniert nicht, man muss „.snapshots“ komplett ausschreiben).

Darin findet man in Unterverzeichnissen (hourly.*/, 6hour.*/, daily.*/ und weekly.*/) den Versionsstand der letzten Stunden, Tage oder Wochen.

Die Dateien im Snapshotverzeichnis belegen weiterhin Speicherplatz im Filesystem! So ist es möglich, dass Sie die Quota für Ihr Homeverzeichnis bereits überschreiten, obwohl ein 'df' noch freien Platz anzeigt. Desweiteren können Sie Snapshots nicht selbst löschen (denn ein Löschen entfernt die Dateien nur aus der aktuellen Sicht, nicht jedoch aus dem Snapshotbereich).
In dringenden Fällen können wir Snapshots auf administrativer Ebene löschen und damit wieder Platz freigeben.

Durch häufiges Anlegen und Löschen von Dateien füllt sich der Snapshot-Bereich (und damit Ihre Quota) schneller und beansprucht mehr Platz im Homeverzeichnis. Darum sollte häufiges Anlegen/Löschen von Dateien in $HOME vermieden werden. Darum: benutzen Sie keine home-, groups- oder projects-Verzeichnisse für die I/O-Dateien laufender Jobs!