Hardware


Die VPP700 Serie von Fujitsu

Die Rechner der VPP-Serie sind skalierbare, vektorparallele Rechner der Firma Fujitsu Ltd. Rechner dieses Typs werden seit der zweiten Hälfte 1996 an europäische Kunden ausgeliefert. VPP steht für "Vector Parallel Processor". Die VPP-Serie ist eine Weiterentwicklung der VP-, S- und VPP500-Serien und ist in den Modellreihen VX, VPP300, VPP700 und VPP5000 lieferbar. Die Modellreihen der VPP-Serie unterscheiden sich in der Maximalzahl der Prozessor-Elemente (VX: bis 4 PEs; VPP300: bis 16 PEs; VPP700: bis 256 PEs) und in der Gestalt des internen Netzwerks. Die lokalen Rechner der Typen VX und VPP300 an den bayerischen Universitäten sind mit dem Landeshochleistungsrechner vom Typ VPP700 am LRZ kompatibel.

VPP 700


Technologie

Die VPP-Serie basiert auf CMOS-Technologie und ermöglicht damit niedrigen Stromverbrauch, geringe Wärmeabgabe und einen günstigen Preis. Die Rechner sind luftgekühlt. Ein CMOS-Chip der VPP-Systeme enthält etwa 8 Millionen Transistoren, und wird in einem 0,35 Mikrometer-Prozeß gefertigt. CPU, Speicher und - bei den VX- und VPP300-Modellen - das interne Netz sind auf einer Prozessorkarte der Größe 37 cm x 48 cm untergebracht. Die Hauptspeicher (MSUs) bestehen aus DRAM-Speicherchips, die eine Kapazität von je 16 MBit und eine Zugriffszeit von 60 ns haben. 

Systemarchitektur

Jedes Prozessor-Element (PE) der VPP-Serie verfügt über eine Vektoreinheit mit einer Spitzenleistung von 2,2 GFLOPS und einen lokalen Hauptspeicher mit wahlweise 2 GByte oder 0,5 GByte. Am LRZ wurde die 2 GByte Version gewählt. Eine voll ausgebaute Maschine der Baureihe VPP700 mit 256 Prozessoren hätte eine Spitzenleistung von 563 GFLOPS und insgesamt 512 GByte verteilten Hauptspeicher.

Die PEs kommunizieren über ein homogenes, konfliktfreies Kreuzschienen-Netz (crossbar network). In diesem internen Netz sind alle PEs gleichberechtigt; bei der Parallelisierung von Programmen muß die Netzwerktopologie nicht berücksichtigt werden.

Hinsichtlich Betrieb und Verwaltung der Maschine spielt das PE0 (primary PE, P-PE) eine ausgezeichnete Rolle; auf diesem PE läuft z.B. NQS, das System zur Auftragsbearbeitung. Das PE0 verwaltet auch - vor allem bei kleineren Anlagen - die angeschlossenen Platten.

Alle PEs arbeiten im Wesentlichen auf einer einheitlichen gemeinsamen Dateibasis.

Abbildung: Systemarchitektur des VPP


Der VPP700 am LRZ

Am LRZ steht ein Rechner des Typs VPP700/52, d.h. eine Maschine mit 52 Prozessor-Elementen mit je 2 GByte Hauptspeicher. Er ist mit einem Plattenspeicher von insgesamt 1214 GByte ausgestattet, wovon 1123 GByte auf RAID-Plattensystemen zur Verfügung stehen. Die RAID-Platten sind zu gleichen Teilen an insgesamt 5 PEs (sog. IMPEs, IPL Master PEs, die auch I/O abwickeln) angeschlossen; eine Ausnahme bildet das Gen5-XLE-Plattensystem, auf dem insbesondere das Dateisystem /ptmp_vfl_large für große Projekte liegt. Das primäre PE betreibt nur Systemplatten und Netzanschlüsse. Die 5 IMPEs sind ebenfalls mit Netzanschlüssen (FDDI) ausgerüstet.

Zahl Prozessor-Elemente (PEs)52
Hauptspeichergröße in GByte104
Plattenkapazität in GByte1214
Taktzeit in ns7
Taktfrequenz in MHz143
Zugriffszeit des Hauptspeichers in ns60
Max. Vektorleistung pro PE in GFLOPS2,2
Max. Skalarleistung pro PE in GFLOPS0,275
Max. Vektorleistung der Maschine in GFLOPS114.4

Tabelle:  VPP700 am LRZ

Der VPP700 am LRZ wird sowohl als Vektorrechner als auch als Parallelrechner betrieben. Das heißt, es gibt sowohl dedizierte PEs und zugehörige NQS-Jobklassen für sequentielle vektorisierte Programme als auch für parallele vektorisierte Programme. Parallele Programme, die nicht gleichzeitig vektorisierbar sind, sollten auf dem Linux-Cluster oder der IBM-SMP (Typ Regatta) gerechnet werden.


 

Partitionierung der VPP am LRZ

Bei den Vektorrechnern der Serie VPP muss die Verwendung des Memory vom Systemadministrator festgelegt werden. Man unterscheidet 4 Typen von Memoryverwendung:

  • Skalares Memory>: zum Ausführen von nicht-vektoriellen Executables und von den meisten Betriebssystemoperationen. Dieses Memory unterliegt einer virtuellen Speicherverwaltung. Hierbei wird eine Seitengröße von 32K verwenden.
  • Vektorielles Memory: zum interaktiven Ausführen von vektoriellem Programmen. Vektoriell ablaufende Programme (das sind i.a. alle Programme, die mit dem Fortran-Compiler frt und dem C-Compiler vcc übersetzt wurden, auch wenn sie ohne Vektorisierungsoption übersetzt wurden) müssen zur Ausführung einschließlich aller Datenfelder im Speicher verfügbar sein. Hier wird eine logische Aufteilung in Blöcke von 8 MByte verwendet. Vektorprogramme unterliegen nicht der virtuellen Speicherverwaltung.
  • Partition Managed Memory: ähnlich wie Vektorielles Memory. Die Zuweisung des Memorys für JOBEXEC- und NQS-Jobs erfolgt jedoch durch den Partition Manager, der je nach Memory-Priorität ggf. Jobs auf Platte auslagert und andere vorzieht.
  • Memory Resident File System: In diesen Teil des Memorys stehen Filesysteme zur Verfügung, die exterm schnelle I/O-Operationen ermöglichen, da die Files nicht auf Platte geschrieben werden müssen (Zugriff über /mrfs1,..,/mrfs5).

Prozessorelemente (PEs) mit gleicher Memory-Konfiguration bzw. gleichen Funktionalität werden (vom LRZ) als Pools bezeichnet. Folgende Pools existieren:

  • Primary-PE: PE mit zentralen Diensten wie NQS, Partition Manager etc.
  • I/O-PEs / IMPEs: PEs mit direkter I/O-Funktionaliät, Login-PEs, Master-PEs fuer die PEs in einer IPL-Gruppe.
  • Development Pool: zusätzlich interaktiv zugreifbare PEs
  • Sequential Pool: Sequentielle Batch-Jobs
  • Parallel Pool: Parallele Batch-Jobs

Abbildung: Memory-Konfiguration der VPP am LRZ, Angabe der Memorygröße jeweil in MByte.




Betriebssystem UXP/V

Die VPP-Serie wird mit dem Betriebssystem UXP/V betrieben. Dies ist eine Variante von UNIX System V Release 4 und unterstützt die wesentlichen Elemente der Standards SVID Version 3, IEEE Posix 1003.1 und XPG3. Fujitsu hat einige Erweiterungen für den Betrieb in Rechenzentren vorgenommen. Auf jedem PE läuft eine Kopie dieses Betriebssystems, jedoch operieren alle Kopien auf einer einheitlichen Dateibasis. Benutzerprogramme können von allen PEs aus in gleicher Weise auf Dateien zugreifen.

Benutzer können sich mit SSH (Secure Shell) oder SCP (Secure Copy) mit jedem PE verbinden, das für interaktiven Zugang konfiguriert ist. Dies sind am LRZ die 5 IMPEs und das primäre PE. Stapelaufträge werden mit NQS verwaltet, welches auf dem primären PE läuft. Die Zuteilung von NQS-Jobs zu PEs erfolgt in Abhängigkeit von den angeforderten Betriebsmitteln durch das PMS (partition manager system). Benutzerjobs können ein PE exklusiv (simplex mode) oder zusammen mit anderen Jobs nutzen (shared mode). Die exklusive Nutzung von PEs ist am LRZ nur für Paralleljobs vorgesehen (paralleler Pool, s.u.)

Das Betriebssystem beherrscht virtuelle Speicherverwaltung (paging). Dies wird aber nur für skalare Programme, das sind im wesentlichen die Betriebssystemkommandos, genutzt. Benutzerprogramme sollen immer vektorisiert oder jedenfalls automatisch vektorisierbar sein (sonst ist der VPP der ungeeignete Rechner); Vektorprogramme sind jedoch auf den realen Hauptspeicher beschränkt und können allenfalls als ganzes auf Platte ausgelagert werden (swapping).

Das Betriebssystem UXP/V ist ein 32-Bit-System. Die Vektoreinheiten arbeiten jedoch mit Worten von 64 Bit. Dabei werden ganze Zahlen auf Gleitkomma-Zahlen abgebildet, wobei effektiv nur 32 Bit zur Verfügung stehen; dies bedeutet, daß ganze Zahlen nur dann vektoriell verarbeitet werden können, wenn sie als integer*4 definiert sind (integer*8 geht nur skalar). Die Skalareinheit kann sowohl 32-Bit- als auch 64-Bit-Worte verarbeiten.

Abbildung: gleichzeitige Ausführung mehrerer Jobs auf dem VPP



Architektur der Prozessor-Elemente (PEs)

Hauptbestandteile eines Prozessor-Elements sind die Skalareinheit (scalar unit, SU), die Vektoreinheit (vector unit, VU), der Hauptspeicher (main storage unit, MSU) und die Datentransfereinheit (data transfer unit, DTU). Beim primären PE und bei den IMPEs kommen noch Einrichtungen für Ein-/Ausgabe hinzu. Sowohl die Skalareinheit als auch die Vektoreinheit führen Gleitkomma-Arithmetik nach dem Standard IEEE-754 durch und sind damit mit den anderen Supercomputern des LRZ und mit Workstations kompatibel.


Abbildung 3: Blockdiagramm eines PEs (Anklicken für Details)


Skalareinheit

Die Skalareinheit (SU) entschlüsselt alle Anweisungen und sendet Vektorbefehle an die Vektoreinheit weiter. Sie kann parallel zur Vektoreinheit weitere Skalarbefehle ausführen, sofern die Datenabhängigkeiten dies zulassen.

Die Skalareinheit arbeitet nach dem RISC-Prinzip mit langem Instruktionswort (LIW, 8 Byte), das die parallele Bearbeitung von bis zu 3 Operationen pro Maschinenzyklus ermöglicht. Gleitkomma-, Vektor­, Speicher- und Kommunikationsoperationen können parallel gestartet werden und werden asynchron ausgeführt. Zwei der drei Operationen können Gleitkomma-Arithmetik durchführen. Damit kann in der Spitze eine Befehlsrate von über 400 MIPS und eine skalare Gleitkomma-Leistung von 275 MFLOPS erreicht werden.


Vektoreinheit

Die Vektoreinheit (VU) enthält insgesamt 7 "pipelines" für Multiplikation, Addition/Logik, Division, Masken (2), Laden und Speichern. Zwei der drei Arithmetik-Pipelines und die übrigen Pipelines können parallel arbeiten. Sie sind 8-fach ausgelegt und können in jedem Takt 8 Ergebnisse produzieren; dies ergibt bei Verkettung von Addition und Multiplikation eine vektorielle Spitzenleistung von 2,2 GFLOPS. Allerdings laufen Vektoroperationen, die ständig zwei Operanden aus dem Hauptspeicher nachladen müssen, deutlich langsamer, da es nur eine Lade-Pipeline (die Cray T90 hatte 2) gibt. Die Pipelines operieren auf Vektorregistern, die insgesamt 128 KByte umfassen und dynamisch konfigurierbar sind: Der Compiler wählt hierzu Zweierpotenzen zwischen 8 x 2048 und 256 x 64 Worten zu je 8 Byte. Optimale Vektorlängen liegen also im Bereich von 64 bis 2048 Worten. Neben der Verkettung von Vektorpipelines (chaining) wird Sammeln und Zerstreuen von Feldelementen (gather/scatter) unterstützt.

Die wesentlich schnellere Verarbeitung von vektorisierbaren Operationen (bis 2,2 GFLOPS) gegenüber den skalaren Operationen (bis 275 MFLOPS) zeigt, daß dieser Rechner nur für vektorisierbare Programme eingesetzt werden soll. Für rein skalare Programme sind das Linux-Cluster oder die IBM-SMP am LRZ die besseren und vermutlich auch schnelleren Maschinen.


Hauptspeichereinheit

Die Hauptspeichereinheit (MSU) hat eine Kapazität von 2 GByte pro PE. Davon stehen am LRZ je nach Konfiguration des Speichers maximal bis zu 1800 MB für einen einzelnen Job zur Verfügung. Die Zugriffszeit ist 60 ns. Eine Speicherbank wird durch einen Zugriff für 20 Takte gesperrt (bank busy). Durch 512-fache Verschränkung (512 Bänke) wird eine Speicherbandbreite von 18,2 GByte/s pro PE ermöglicht. Damit können die Vektorpipelines kontinuierlich mit Daten versorgt werden (Einschränkung siehe oben). Adressierungseinheit ist das Byte.

Üblicherweise nutzen parallele Programme diese Maschine als Distributed Memory Maschine, wobei auf jedem PE ein Prozess mit eigenem Adressraum abläuft. Die Prozesse eines parallelen Programmes tauschen dann Daten via Message Passing aus. Für spezielle (daten)parallele Fortran-Prozesse kann die Data Transfer Unit (s.u.) auch einen virtuell globalen Speicher, der sich über mehrere reale Hauptspeicher (MSUs) erstreckt, realisieren. Bei der Nutzung von derzeit maximal 16 PEs steht dann ein globaler Speicher von maximal etwa 28 GByte zur Verfügung.


Data Transfer Unit

Die Data Transfer Unit (DTU) realisiert die Verbindung zum (Crossbar Network) und arbeitet ohne Intervention des Betriebssystems. Die DTU arbeitet asynchron zur SU und zur VU und kann daher Datentransfers parallel zur Berechnung ausführen. Jede DTU kann simultan Daten an ein anderes PE senden (nicht an mehrere gleichzeitig) und Daten von diesem PE empfangen. Die maximale Datentransferrate beträgt 2x570 Mbyte/s.

Die Transferaufträge werden in einer Warteschlange gespeichert und nacheinander abgearbeitet. Ein einzelner Transfer kann bis zu 16 MByte übertragen. Außerdem verfügt die DTU über ein Register für die schnelle Barrier-Synchronisation.

Das interne Netz wächst linear mit der Zahl der PEs. Bei 52 PEs beträgt die gesamte Transferleistung in der Spitze 52 x 570 Mbyte/s.



Die Programmierumgebung der VPP-Serie


Compiler

Als Standard-Programmiersprache für technisch-wissenschaftliche Anwendungen gibt es auf der VPP-Serie ein umfangreiches Fortran90-Programmiersystem. Der Compiler verfügt über automatische Vektorisierungs- und Optimierungstechniken. Die Erkennung vektorisierbarer Programmteile kann durch den Programmierer mit Hilfe von Compilerdirektiven unterstützt werden. Im Unterschied zu den Cray Vektorrechnern sind die Vektorregister des VPP dynamisch rekonfigurierbar. Neben dem Fortran90-Compiler stehen noch ein skalarer und ein vektorisierender C-Compiler sowie ein C++-Compiler bereit.


Parallele Programmiermodelle

Die Parallelverarbeitung auf mehreren Prozessorelementen wird durch zwei Programmiermodelle unterstützt:

  • Datenparalleles Programmiermodell mit Fortran90/VPP
    Hierbei können Felder mittels Compiler-Direktiven über den Speicher der angeforderten Prozessorelemente verteilt werden. Der Programmierer hat eine globale Sicht auf den an sich verteilten Speicher. Die Hardware führt die Umsetzung auf die physische Prozessornummer und Speicheradresse durch. Die Parallelisierung des Programms wird im wesentlichen mittels SPREAD-DO (für Schleifen) und SPREAD-REGION-Direktiven durchgeführt. Das datenparallele Programmiermodell ähnelt in vielerlei Hinsicht dem Modell von HPF (High Performance Fortran).
  • Message Passing
    Wesentlich universeller als die Parallelisierung mit Fortran90/VPP ist die Message Passing basierende Programmierung mit MPI, PVM oder einer anderen Bibliothek wie PARMACS. Auf anderen Rechnern entwickelte Message Passing Programme können somit leicht auf den VPP-Rechner portiert werden. Bei MPI gibt es keine wesentliche Einschränkung, bei PVM wird derzeit nur das SPMD (Single Program Multiple Data)-Modell unterstützt. Eine dynamische Generierung von Prozessen ist nicht möglich. Erfahrungen von der IBM SP2 zeigen aber, daß dies in den meisten Fällen keine wesentliche Einschränkung bedeutet.


Meß- und Analyse-Werkzeuge

Es gibt verschiedene Werkzeuge, mit denen von der Hardware gesammelte Informationen ausgegeben werden können. Das Werkzeug MPA sammelt Informationen bezüglich Datenübertragung im Crossbar-Netzwerk. Mit dem Werkzeug PEPA werden Performance-Informationen auf den Prozessorelementen gesammelt, insbesondere erhält der Programmierer dabei Informationen über die Ausnutzung der Vektoreinheiten und über die Floating-Point-Leistung seines Programms. Mit dem Produkt UXP/V Analyser können Informationen über die Performance für parallele als auch vektorielle Programme gesammelt werden. Das "Sampling" geschieht dabei auf Basis der CPU- oder Verweilzeit mit vom Benutzer frei wählbarem Sampling-Intervall. Als Ausgabe erhält der Benutzer ein Programmprofil, das die Kosten pro Routine und auf Routinenebene die Kosten einzelner Schleifen aufzeigt. 

Werkzeuge zur Fehlersuche

Durch Compileroptionen können sowohl der Datentyp als auch die Feldgrenzen überwacht werden. Fehlersituationen wie Overflow oder Underflow werden erkannt und können durch Serviceroutinen behandelt werden. Ein symbolischer Dump kann über Compileroptionen, Runtime-Optionen und Serviceroutinen gesteuert werden. Corefiles und Programme können mit dem Debugger fdb analysiert werden. Bei Message Passing-Programmen kommt der schon von den Cray-Rechnern her bekannte Debugger "Totalview" der Firma Dolphin zum Einsatz. 

Bibliotheken und Software

Die Bibliotheken IMSL, NAG, BLAS und LAPACK sind für die VPP-Serie in vektorisierten Versionen vorhanden. Zusätzlich gibt es die herstellereigene Scientific Subroutine Library (SSL II), die über 900 vektorisierte Routinen aus den Bereichen Lineare Algebra, Eigenwerteprobleme, Optimierung, Differentialgleichungen und Integration enthält. Derzeit stehen ungefähr 40 parallelisierte Routinen für Matrixoperationen, lineare Gleichungssysteme, Eigenwertprobleme und Fourier-Transformation zur Verfügung.


 

Filesysteme

Dateien werden - abgesehen von den Systemdateien - auf drei unterschiedlichen Arten von Platten-Systemen in RAID-Technologie gehalten: (1) fünf langsame Platten-Systeme des Typs F6401H von der Firma Hitachi mit einer Gesamtkapazität von 248 GByte und einer maximalen Übertragungsrate von 20 MByte/s pro System; (2) vier schnelle Platten-Systeme des Typs Gen5L von der Firma Maximum Strategy mit einer Gesamtkapazität von 510 GByte und einer Übertragungsrate von 70 MByte/s; (3) ein schnelles neues Platten-System des Typs Gen5-XLE von der Firma Maximum Strategy mit einer Gesamtkapazität von 364 GByte und einer Übertragungsrate von 62 MByte/s. Permanente Benutzerdateien liegen auf den langsameren Platten, temporäre Dateien auf den schnellen.

Die Platten werden zu gleichen Teilen an die 5 IMPEs angeschlossen; Ausnahme: Gen5-XLE-Plattensystem mit dem Dateisystem /ptmp_vfl_large für große Projekte. Damit zerfällt die Plattenbasis in zehn Teile, die den verschiedenen Benutzergruppen (TU München, LMU München , Erlangen etc.) zugewiesen werden.

Auf den Platten werden zwei Arten von Dateisystemen mit stark unterschiedlicher Charakteristik eingerichtet: Der Standardfall ist ufs (UNIX Filesystem). Daneben gibt es Filesysteme vom Typ vfl-fs (very fast and large file system), welche nur für wirklich große Dateien geeignet sind und unter Umgehung einer Systempufferung genutzt werden.


Typen von Dateisystemen

Für den Benutzer ergibt sich folgende Sicht auf die Filesysteme:

  • Home-Filesysteme
    Diese enthalten die permanenten Benutzerdateien wie Programmquellen, kleinere Eingabedatensätze, wichtige Ergebnisdaten etc. Diese Dateisysteme werden vom LRZ in regelmäßigen Abständen gesichert. Der Benutzer kann über die Environmentvariable $HOME auf seine Daten zugreifen. Ein Kontingentierungssystem überwacht dynamisch den Umfang und die Zahl der Dateien.

  • Temporäre Filesysteme
    Ein direkter Zugriff auf das in der Unix-Welt übliche Filesystem /tmp ist aus Gründen des reibungslosen Betriebs nicht sinnvoll. Unberechtigt dort angelegte Files werden deshalb vom LRZ nach relativ kurzer Zeit entfernt. Statt dessen kann jeder Benutzer auf ein job-temporäres Verzeichnis über die Environmentvariable $TMPDIR zugreifen. Die dort abgelegten Daten und das Verzeichnis $TMPDIR werden nach Jobende vom LRZ gelöscht. Die Verzeichnisse $TMPDIR liegen im pseudotemporären Dateisystem (s.u.) vom Typ UFS; sie unterliegen jedoch nicht der Gleitlöschung, damit die Existenz dieser Dateien bis zum Ende des jeweiligen Jobs gesichert ist. Bitte beachten Sie aber, daß die Dateien in $TMPDIR und in $PTMP_UFS dem gleichen Plattenkontingent unterliegen.

  • Pseudotemporäre Filesysteme
    Diese enthalten Datensätze von Benutzern (z.B. Ausgabedaten, Eingabedaten für Folgeläufe), die mittelfristig aufgehoben werden sollen (ca. 2-4 Wochen). Durch das LRZ erfolgt keine Sicherung dieser Daten , da die zu erwartende Datenmenge in kürzester Zeit ein Archivierungssystem sprengen würde. Die pseudotemporären Filesysteme unterliegen einer Gleitlöschung, d.h. wenn der Füllungsgrad eines Filesystems eine bestimmte Marke überschreitet, werden solange alte Dateien gelöscht, bis wieder ein Füllungsgrad unter einer bestimmten Marke erreicht ist. Das Anstoßen des Löschmechanismus ist, unabhängig von der Menge an Daten, die ein spezieller Benutzer anlegt, sondern hängt davon ab, wie alle Benutzer das Dateisystem gefüllt haben. Gleichwohl gibt es für jeden Benutzer Grenzwerte, um das versehentliche Vollschreiben der Filesysteme zu verhindern. Jeder Benutzer kann seine Daten in zwei pseudotemporären Filesystemen ablegen:

    • $PTMP_UFS (Unix File System) mit einer Kapzität von 32 GB pro Benutzergruppe (Gesamtkapzität 160 GB) dient zum Aufbewahren von vielen kleineren Datensätzen.
    • $PTMP_VFL (Very Fast and Large) mit einer Kapzität von 60 GB (Gesamtkapazität 300 GB) dient zum Aufbewahren von wenigen sehr großen Datensätzen, die in großen Blöcken aus Programmen heraus geschrieben werden.
  • Filesystem für große Projekte: /ptmp_vfl_large
    Das Dateisystem /ptmp_vfl_large dient der Bearbeitung einzelner Projekte mit grossem Platzbedarf. Es steht allen Nutzern des VPP700 offen. Die Berechtigung zur Nutzung wird jedoch nur auf Antrag und nur für beschränkte Zeit gewährt. Antrag am besten per Email an vpp-admin@lrz-muenchen.de.

  • Memory Resident Filesysteme
    Programme, die mit hoher Frequenz kleine Dateien nutzen (z.B. Compiler), können diese in den Hauptspeicher legen und damit eine erhebliche Leistungssteigerung erreichen. Dazu werden vom Systemverwalter und/oder Benutzer sog. mrfs (memory resident file system) eingerichtet. Ein mrfs kann eine Transferrate von 600 MByte/s erreichen. Der Speicherplatz, den das jobtemporäre mrfs verbraucht, wird dem Benutzerjob angerechnet. Nach Beendigung des Jobs wird das jobtemporäre mrfs gelöscht, so daß alle Dateien, die erhalten bleiben sollen, auf ein plattenbasiertes Filesystem wie $HOME oder $PTMP kopiert werden müssen. Insgesamt stellt die Verwendung von mrfs die schnellste I/O-Art dar.

Abbildung: Relative Größe der Filesysteme an der VPP


Core-File Löschung

Auf den File-Systemen /home (Home-Directories) und /ptmp_* (pseudo-temporäre Daten) werden einmal wöchentlich über einen cron-Job alle Files mit dem Namen core gelöscht. 

Archivierung

Zur langfristigen Archivierung von Daten steht an der VPP700 ein ADSM-Client zur Verfügung, mit dem der Benutzer bequem Daten in das robotergestützte Archivierungssystem des LRZ übertragen kann.

  • No labels