VOICE Homepage: http://www.os2voice.org

[Newsletter Inhalt] [Vorherige Seite] [Nächste Seite] [Artikelübersicht]

Grundsätzliches

Zu allererst werde ich jetzt endlich diese Begriffe auflösen: LVM steht für Logical Volume Manager und JFS ist ein Journaled File System. Noch nicht unbedingt klarer, nicht wahr? Das kommt noch - hoffe ich.

LVM und JFS stammen nicht von OS/2 ab. Sie wurden für AIX entwickelt, also für das IBM'sche high-end Unix-Derivat, das auf den RS/6000-Maschinen (ebenfalls aus dem Hause IBM) läuft. Für den Anwender bedeutet das, daß die wirklich bösen Fehler bereits seit geraumer Zeit ausgemerzt sind.

LVMs Rolle ist es nun, eine einfache logische Sicht für den darunter liegenden physikalischen Speicherplatz herzustellen. LVM verwaltet individuelle physikalische Laufwerke bzw., um etwas präziser zu sein, die individuellen Partitionen darauf. (Am Ende des Artikels ist ein kleines Glossar für diese Begriffe.) LVM verbirgt Anzahl, Ort und Größe der physikalischen Partitionen vor dem Anwender. Statt dessen verwendet er das Konzept logischer Volumen. Ein logisches Volumen kann einer physikalischen Partition entsprechen (obwohl das eigentlich schon dem Sinn und Zweck des LVM widerspricht) - muß es aber nicht. Ein Volumen kann aus mehreren Partitionen bestehen, die sich auf mehreren physikalischen Laufwerken (Festplatten) befinden. Nicht nur das - diese Volumen können auch erweitert werden (nicht verkleinert - für gewöhnlich möchte man ja mehr Platz haben, nicht weniger). Diese Vergrößerung kann sogar im laufenden Betrieb stattfinden! Natürlich haben nur wenige SOHO-Anwender die Hardware-Ausstattung, die hierfür notwendig ist.

Der erfahrenere Leser wird sich nun wahrscheinlich fragen, wie man ein "traditionelles" Dateisystem wie etwa FAT oder HPFS im laufenden Betrieb vergrößern könnte. Die Antwort ist: Man kann es nicht. Um in den Genuß aller Vorteile des LVM zu kommen, muß man ein Dateisystem verwenden, welches hierfür konzipiert wurde. Dieses Dateisystem ist - wie könnte es anders sein - JFS. JFS gehört nicht zwingend zum LVM; sowohl LVM als auch JFS können jeweils separat voneinander betrieben werden. Ihr volles Potential können die beiden jedoch erst ausschöpfen, wenn sie zusammen betrieben werden.

Aufbau eines JFS-Volumens

Kapazität - JFS erlaubt größere Dateien und Platten als HPFS. Im Grunde genommen ist JFS ein 64 Bit-Dateisystem, während die HPFS-Strukturen 32 Bit groß sind.

Wiederherstellung - dank der bei JFS eingesetzten Protokollierungstechnik (Details hierzu folgen weiter unten), ist CHKDSK erheblich schneller als bei entsprechenden HPFS-Datenträgern. Grob gesagt bedeutet das: Wo CHKDSK nach einem Absturz auf HPFS Minuten braucht, dauert es mit JFS nur Sekunden.

dem Superblock

den i-Nodes

den Datenblöcken

den "allocation groups"

Der gesamte Raum des Dateisystems ist in logische Blöcke unterteilt, die Datei- oder Verzeichnisdaten beinhalten. Bei JFS sind die logischen Blöcke zwar grundsätzlich 4096 Bytes groß (4 KB), jedoch können sie optional in kleinere Fragmente (512, 1024 oder 2048 Bytes) unterteilt werden.

Ein i-Node ist eine logische Einheit, die Angaben über eine Datei oder ein Verzeichnis enthält. Das Verhältnis zwischen i-Nodes und Dateien bzw. Verzeichnissen ist 1:1. Ein i-Node enthält Dateityp, Zugriffsberechtigung, Benutzer- und Gruppenkennung (UID/GID - werden bei OS/2 nicht verwendet), Zeitpunkte des Datenzugriffs und verweist auf die eigentlichen logischen Blöcke, in denen der Datei-Inhalt abgelegt ist. Die mit JFS maximal erlaubte Dateigröße beträgt 2TB (HPFS und FAT erlauben hier maximal 2GB). Es muß allerdings darauf hingewiesen werden, daß die Anzahl an i-Nodes fest vorgegeben ist - sie wird bei der Erstellung des Dateisystems (FORMAT) in Abhängigkeit von der Fragmentgröße (die vom Benutzer wählbar ist) berechnet. Theoretisch könnten dem Anwender also die i-Nodes ausgehen und er wäre somit nicht mehr in der Lage, neue Dateien oder Verzeichnisse anzulegen, obwohl noch genügend freier Speicherplatz vorhanden ist. In der Praxis dürfte dieser Fall aber extrem selten auftreten.

Fragmente wurden bereits kurz in Zusammenhang mit logischen Blöcken erwähnt. Die Größe eines logischen Blocks ist bei JFS auf 4KB eingestellt. Das ist zwar ein vernünftiger Vorgabewert, jedoch bedeutet es, daß das Dateisystem nicht weniger als 4K Speicherplatz für eine Datei bereitstellen kann. Wenn im Dateisystem nun eine größere Anzahl an kleinen Dateien (< 2KB) abgelegt wird, macht sich dieser als "Clusterverschnitt" bezeichnete vergeudete Speicherplatz schnell bemerkbar. Dieses Problem kennen und hassen wir alle von FAT (die Clustergröße von 32KB führt zu einer massiven Platzverschwendung, in machen Fällen bis zu 50%). JFS begegnet diesem Problem durch die Möglichkeit der Fragmentierung von logischen Blöcken in kleinere Einheiten von bis zu 512 Bytes (welches der Sektorengröße bei Festplatten entspricht, wodurch es nicht möglich ist, weniger als 512 Bytes pro Zugriff von/zu einer Platte zu übertragen). Jedoch sollten Anwender hier Vorsicht walten lassen, denn der Preis der Fragmentierung ist ein höhere Systemlast und somit eine Verzögerung bei Plattenzugriffen. Ich würde Fragmente von weniger als 4KB Größe nur dann empfehlen, wenn man mit Sicherheit weiß, daß man eine sehr hohe Zahl von kleinen Dateien im Dateisystem speichern will.

Der gesamte Speicherplatz eines JFS-Volumens ist in allocation groups unterteilt (Zuordnungsgruppen, Anm.d.Übers.). Jede Zuordnungsgruppe enthält i-Nodes und Datenblöcke. Dies ermöglicht es dem Dateisystem, den i-Node und die sich dahinter verbergenden Daten physikalisch "nah beieinander" zu speichern (HPFS verwendet eine sehr ähnliche Technik). Die Größe einer allocation group reicht von 8MB bis zu 64MB und hängt von der Anzahl und Größe der enthaltenen Fragmente ab.

Journaling

JFS verwendet ein spezielles Protokollierungslaufwerk um sein Journaling durchzuführen. Bei AIX können sich mehrere JFS-Volumen ein Protokollierungslaufwerk teilen. Ich bin mir nicht sicher, ob dies bei OS/2 auch der Fall ist - ich glaube vielmehr, daß hier jedes JFS-Volumen (was also einem Laufwerksbuchstaben entspricht) seine eigene Protokollierung hat, die im JFS-Volumen eingebunden ist, und deren Größe zum Zeitpunkt der Formatierung bestimmt wird.

Wichtig ist, daß JFS nicht alles protokolliert. Es werden nur die Änderungen an Metadaten des Dateisystems festgehalten. Einfach ausgedrückt werden also alle Änderungen im Dateisystem mit Ausnahme der eigentlichen Datei-Inhalte protokolliert, also z.B. Änderungen am Superblock, den i-Nodes, Verzeichnissen und den Strukturen der allocation groups. Selbstverständlich ergibt sich hieraus eine Lasterhöhung und die Leistung leidet darunter, wenn viele synchrone (ungepufferte) Ein-/Ausgabeoperationen stattfinden, oder auch wenn viele Dateien innerhalb kurzer Zeit angelegt bzw. gelöscht werden. In den meisten Fällen sind diese Leistungseinbußen aber nicht spürbar und sind die erhöhte Sicherheit durchaus wert.

Das Protokoll (oder Journal) belegt einen exklusiven Bereich der Platte und wird sofort bei Änderungen an Metadaten aktualisiert. Sobald sich die Platte im Bereitschaftsmodus befindet (keine Plattenaktivität mehr), wird die eigentliche Dateisystemstruktur anhand der Informationen aus dem Protokoll aktualisiert. Alles, was nach einem Absturz getan werden muß um ein vollkommen konsistentes Dateisystem wiederherzustellen beschränkt sich eigentlich darauf, die im Protokoll aufgezeichneten Aktionen zu durchlaufen. Sollte das System zum Zeitpunkt des Absturz oder Stromausfalls gerade einem Schreibvorgang in eine Datei durchgeführt haben, kann diese Datei natürlich inkonsistent werden (die Anwendung kann die Datei nicht mehr benutzen), jedoch werden keine Dateien mehr verlorengehen, was bei vielen anderen Dateisystemen der Fall ist.

Überlegungen zu OS/2

LVM

FDISK.COM has been replaced by LVM.EXE and FDISKPM.EXE has been
replaced by LVMGUI.CMD. Please use one of these utilities.

(Anm.d.Übers.:
FDISK.COM wurde ersetzt durch LVM.EXE und FDISKPM.EXE wurde ersetzt durch LVMGUI.CMD. Bitte verwenden Sie eines dieser Dienstprogramme.)

Beachten Sie, daß LVMGUI eine GUI-Anwendung ist (wie der Name vermuten läßt) und Java benötigt, während LVM eine VIO-Anwendung ist und aus einer Befehlzeilenumgebung heraus gestartet werden kann (z.B. beim Booten). Es ähnelt zwar FDISK, jedoch hat es zwei Ansichten - logisch und physikalisch. FDISK machte darin keinen Unterschied. Diese Ansichten entsprechen dem, was in den Grundlagen zu Beginn des Artikels erläutert wurde. Die physikalische Sicht verwendet die physikalischen Platten und ermöglicht dem Anwender die Arbeit mit Partitionen, während in der logischen Ansicht mit Volumen gearbeitet wird. Ein wichtiges Grundelement muß hier noch vorgestellt werden: Das compatibility volume (Kompatibilitätsvolumen, Anm.d.Übers.). Ein solches Kompatibilitätsvolumen entspricht den alten FDISK-Partitionen. Während der WSeB-Installation wandelt das Installationsprogramm automatisch alle vorhandenen Partitionen in Kompatibilitätsvolumen um. Diese Konvertierung bedeutet technisch gesehen, daß das Installationsprogramm einen speziellen Block von LVM-Daten in den Sektor schreibt, der sich hinter der Partitionstabelle befindet. Andere Betriebssysteme als WSeB erkennen keinen Unterschied. Es ist jedoch zwingend erforderlich, daß im Anschluß an diese Konvertierung ausschließlich LVM zur Verwaltung der Partitionen bzw. Volumen eingesetzt wird.

Ich habe mehrere Bildschirmabbildungen von LVM und LVMGUI gemacht, damit sich die Anwender, die LVM noch nicht kennen einen Eindruck davon verschaffen können, was auf sie zukommt. Zunächst hätten wir da die logische Sicht von LVM:

Dann die physikalische Sicht desselben Systems.

Und zu guter Letzt ein Blick auf LVMGUI. Es sieht ziemlich cool aus, braucht aber Jahre zum Starten. Persönlich bevorzuge ich die VIO-Version. Übrigens ist Disk 3 ein ZIP-100 und G: ist eine FAT32-Partition.

Alle FAT-, HPFS-, FAT32-Partitionen usw. können entweder auf LVM- oder Kompatibilitätsvolumen abgelegt werden, jedoch können andere Betriebssysteme nur auf Partitionen zugreifen, die sich auf Kompatibilitätsvolumen befinden. Auf der anderen Seite kann JFS nur auf LVM-Volumen eingesetzt werden. Diese wurden bereits weiter oben beschrieben und genießen alle Vorteile, die durch LVM möglich werden wie z.B. die Verteilung auf mehrere physikalische Platten oder Online-Vergrößerung.

Jedes Volumen, Kompatibilitäts- oder LVM-, repräsentiert einen einzelnen Laufwerksbuchstaben in einem OS/2-System. LVM ist aber erheblich flexibler als FDISK, denn die Laufwerksbuchstaben werden nicht nach einem festen Algorithmus vergeben. Statt dessen kann der Anwender den Volumen beliebige Buchstaben zuordnen. Diese Buchstaben können sogar im laufenden Betrieb geändert werden, jedoch sollte man sich über die Gefahren im Klaren sein, die sich daraus ergeben können. Wenn man beispielsweise den Buchstaben des Bootvolumens ändert, braucht man kein Genie zu sein um sich auszumalen, daß ein Systemabsturz die wahrscheinlichste Folge sein wird.

JFS

1) JFS speichert Datei- und Verzeichnisnamen in Unicode. Dadurch kann JFS grundsätzlich die korrekte Sortierreihenfolge gewährleisten unabhängig von der aktiven Codepage.
2) Dies ist keine grundsätzliche Einschränkung. Es hat nur noch niemand ein Micro- bzw. Mini-IFS für JFS geschrieben.

Es dürfte einige Anwender interessieren, daß JFS scheinbar auch von Hause aus DASD-Limits unterstützt. Ich habe diese Eigenschaft bisher allerdings noch nie verwendet. DASD-Limits, auch bekannt als das "Directory Limits"-Feature im LAN Server ermöglicht es einem Administrator, zu kontrollieren, wieviel Speicherplatz ein Verzeichnis belegen darf - um zum Beispiel den Speicherplatz von Netzwerkanwendern auf dem Server zu beschränken. Dieses Merkmal gab es vorher nur für HPFS386-Volumen. Offensichtlich ist das nicht unbedingt von direktem Nutzen für Heimanwender, die Ihren gesamten Plattenspeicher für sich alleine haben - es könnte aber sehr nützlich sein für Systemadministratoren.

JFS Hilfsprogramme

DEFRAGFS - kann zur Defragmentierung und Reorganisation eines JFS-Volumens verwendet werden. Es ähnelt den entsprechenden Programmen für FAT oder HPFS. Zu erwähnen ist, daß JFS wie auch HPFS von vornherein eine Fragmentierung von Dateien zu vermeiden versuchen. Dies ist allerdings nicht immer möglich - speziell auf fast vollen Volumen. Zusätzlich versucht DEFRAGFS noch, die internen JFS-Strukturen zu optimieren, indem bestimmte Datenblöcke nah beieinander gespeichert werden, wodurch der Plattenzugriff beschleunigt wird. DEFRAGFS ist für Hintergrundverarbeitung ausgelegt.

EXTENDFS - nach der Vergrößerung eines LVM-Volumens wird JFS mit diesem Hilfsprogramm mitgeteilt, daß es den gesamten nun verfügbaren Speicherplatz belegen soll.

CACHEJFS - in der Befehlsübersicht nicht dokumentiert. Mit diesem Programm können die Einstellungen des JFS-Caches abgefragt und die Parameter der Schreibverzögerung eingestellt werden.

CHKLGJFS - ebenfalls undokumentiert. Es ist ein Diagnoseprogramm, das ein aufbereitetes Protokoll des letzten (oder vorletzten) Laufs von CHKDSK anzeigt. Nicht unbedingt von Nutzen für den Normalanwender.

LOGDUMP - wie der Name bereits verrät kann hiermit das JFS-Protokoll in aufbereiteter Form in eine Datei geschrieben werden.

CSTATS - gibt die aktuellen Statistiken des JFS-Caches aus.

XPEEK - vielleicht das nützlichste dieser Sammlung. Es ist das Programm, welches meiner Meinung nach einem JFS-Diskeditor am nächsten kommt. Mit diesem Programm kann man interne JFS-Strukturen offenlegen und optional auch bearbeiten. Es hat eine sehr grobe Bedienerführung aber für meine Zwecke hat es genügt. Überflüssig zu erwähnen, daß dieses Programm extrem gefährlich ist und man damit sehr einfach Daten zerstören kann, wenn man nicht hundertprozentig weiß, was man da gerade macht.

Schlußfolgerung

Ein letztes Wort: Alles, was hier über WSeB gesagt wurde, trifft genauso auf eCS zu.

Glossar:

Partition - ein Teil physikalischen Plattenplatzes. Eine Festplatte kann eine oder mehrere Partitionen enthalten. Partitionen werden durch das BIOS des PC definiert und durch Partitionstabellen beschrieben wird, die auf einer Festplatte gespeichert sind. Jedes PC Betriebssystem versteht Partitionen.

Volumen - eine logische Betrachtungsweise, bei der die physikalische Organisation der Speicherplatzes verborgen bliebt. Ein Kompatibilitätsvolumen entspricht direkt einer Partition, wohingegen sich ein LVM-Volumen über mehr als eine Partition und/oder physikalische Festplatte erstecken kann. Ein Volumen erscheint für den Anwender als einzelner Laufwerksbuchstabe. Nur WSeB und eCS können mit LVM-Volumen arbeiten.

DASD - Direct Access Storage Device. (Direktzugriffs-Speichergerät, Anm.d.Übers.) Ein Begriff, der des Öfteren von IBM anstelle von "Festplatte" verwendet wird, um uns einfache Sterbliche zu verwirren.