Deutsch 
English Kapitel 5 - Der Dateisystem-Manager
Der Dateisystem-Manager
Dieses Kapitel enthält die folgenden Themen:
- Einführung
- Was ist eine Datei?
- Reguläre Dateien und Verzeichnisse
- Links und Inodes
- Symbolische Links
- Pipes und FIFOs
- Dateisystem-Manager-Performance
- Dateisystem-Robustheit
- Blockorientierte Geräteeinheiten (raw volumes)
- Schlüsselkomponenten einer QNX-Partition
- Der DOS-Dateisystem-Manager
- Das CD-ROM-Dateisystem
- Das Flash-Dateisystem
- Das NFS-Dateisystem
- Das SMB-Dateisystem
Einführung
Der Dateisystem-Manager (Fsys) bietet standardisierte Wege für das Speichern und den Zugriff auf Daten eines Festplatten-Subsystems. Fsys bearbeitet alle Anfragen durch open(), close(), read() und write()-Funktionen.
Was ist eine Datei?
Unter QNX ist eine Datei ein Objekt, in das geschrieben und/oder von dem gelesen werden kann. QNX implementiert sechs verschiedene Typen von denen fünf vom Fsys verwaltet werden:
- Reguläre Dateien - erscheinen als Sequenzen von Bytes, auf die wahlfrei zugegriffen werden kann. Sie besitzen keine definierte Stuktur.
- Verzeichnisse - enthalten Informationen darüber, wo sich reguläre Dateien befinden; sie liefern auch die Informationen über den Status und die Attribute einer regulären Datei.
- Symbolische Links - enthalten Pfadnamen zu einer Datei oder einem Verzeichnis auf welches mit dem auf eine symbolisch gelinkte Datei oder Verzeichnis zugegriffen wird. Diese symbolischen Links werden oft benutzt, um mehre Zugriffspfade für ein und dieselbe Datei zu haben.
- Pipes und FIFOs - arbeiten als Verbindungskanal zwischen kooperierenden Prozessen.
- blockorientierte Dateien - verweisen auf Geräte wie Harddisks, Tapes und Harddisk-Partitionen. Diese Dateien werden normalerweise benutzt, um Hardware-Eigenschaften vor dem Anwender zu verbergen.
Alle zuvor genannten Dateitypen werden nun im Detail besprochen. Der sechste, zeichenbasierte Dateityp, wird vom Geräte-Manager verwaltet. Andere Typen könnten von anderen Managern verwaltet werden.
Zeit und Datumsstempel
Der Fsys pflegt vier verschiedene Zeiteinträge für jede Datei:
- Datum des letzten Zugriffs (lesen)
- Datum des letzten Schreiben (write)
- Datum der letzten Modifikation
- Datum der Erzeugung (nur für QNX)
Dateizugriff
Der Zugriff auf Dateien und Verzeichnisse wird durch sogenannte Mode-Bits definiert. Diese sind im Inode (siehe Abschnitt ``Links und Inodes'') der Datei abgelegt. Diese Bits regeln den Lese-, Schreib- und Ausführungszugriff, basierend auf der effektiven Benutzer und Gruppen ID. Es existieren drei Zugriffsgruppen:
- Nur Besitzer
- Nur die Gruppe
- Jeder andere
Ein Prozeß kann auch mit den Besitzer- und Gruppenrechten einer Datei laufen, statt diese vom Vaterprozeß zu erben. Der Mechanismus, der dies ermöglicht, wird als setuid (Setze Besitzer ID bei der Ausführung) und setgid (setze Gruppen ID bei der Ausführung) bezeichnet.
Reguläre Dateien und Verzeichnisse
Reguläre Dateien
QNX betrachtet reguläre Dateien als eine Sequenz von Bytes, auf die wahlfrei zugegriffen werden kann, ohnen daß diese eine definierte Struktur haben muß. Es bleibt der Anwendung überlassen, die Struktur oder den Inhalt einer Datei zu interpretieren.
Reguläre Dateien kommen mit Abstand am häufigsten in Dateisystemen vor. Dateisysteme werden vom Dateisystem-Manager unterstützt und sind auf der Basis von blockorientierten Festplattenpartitionen implementiert. (siehe Abschnitt ``Blockorientierte Geräteeinheiten (raw volumes)'').
Verzeichnisse
Ein Verzeichnis ist eine Datei die Verzeichniseinträge enthält. Jeder Verzeichniseintrag korrespondiert mit dem Dateinamen einer Datei. Ein Dateiname ist eine symbolische Bezeichnung, über die auf eine Datei zugegriffen werden kann. Dabei ist es möglich auf eine Datei über mehrere Namen zuzugreifen. (siehe Abschnitt ``Links und Inodes'' und `` Symbolische Links'').
Die folgende Abbildung zeigt eine Verzeichnisstruktur die benutzt wird, um die Datei /usr/bill/file2 zu lokalisieren.
Der Pfad durch die QNX-Verzeichnisstruktur bis zur Datei /usr/bill/file2.
Verzeichnis-Operationen
Auch wenn ein Verzeichnis wie eine Standarddatei aussieht, belegt der Dateisystem-Manager sie mit einigen Restriktionen. Sie können eine solche Datei weder zum Schreiben öffnen, noch können Sie einen Link mit der link() Funktion auf ein Verzeichnis ausführen.
Lesen von Verzeichniseinträgen
Um Verzeichniseinträge zu lesen, bedienen Sie sich der in POSIX definierten Funktionen, welche betriebssystemunabhängig sind. Diese Funktionen sind:
- opendir()
- readdir()
- rewinddir()
- closedir()
Da QNX-Verzeichnisse wie einfache Dateien behandelt werden können und deren Struktur bekannt ist, ist es möglich die Verzeichniseinträge direkt zu lesen, indem man die open() und read() Funktionen nutzt. Diese Vorgehensweise ist jedoch nicht portabel, da die Einträge auf anderen Betriebssystemen eine andere Struktur haben können.
Erweiterungen (Extents)
In QNX werden reguläre Dateien und Verzeichnisdateien als Sequenz von Erweiterungen (extents) gespeichert. Erweiterungen werden als zusammenhängende Blöcke auf der Disk gespeichert.
Ablage von Erweiterungen
Dateien, die nur eine Erweiterung haben, speichern ihre Informationen direkt im Verzeichniseintrag. Wenn jedoch mehr als eine Erweiterung nötig ist, um alle Informationen zu einer Datei festzuhalten, wird die Lage der Erweiterung in einer verketteten Liste aus Erweiterungsblöcken gespeichert. Jeder Erweiterungsblock kann wiederum 60 Einträge zu weiteren Erweiterungen aufnehmen.
Eine Datei, abgebildet als fortlaufende Verkettung von Regionen - in QNX ``Extents'' genannt.
Erweitern von Dateien
Wenn der Dateisystem-Manager einen Extend-Block erweitern muß, also dessen letzte Erweiterung voll ist, versucht er zunächst den letzten Extend-Block zu verwenden, auch wenn die Erweiterung nur ein Block beträgt. Wenn der letzte Block nicht erweitert werden kann, wird ein neuer alloziert.
Um neue Erweiterungen zu allozieren, benutzt der Dateisystem-Manager das Prinzip ``Wer zuerst kommt mahlt zuerst ''. Eine spezielle Tabelle im Dateisystem-Manager beinhaltet für jeden Block einen in der /.bitmap Datei stehenden Eintrag (diese Datei wird in dem Abschnitt ``Schlüsselkomponenten einer QNX Partition '' beschrieben). Jeder dieser Einträge beschreibt den größten freien zusammenhängenden Erweiterungsblock. Der Dateisystem-Manager wählt den ersten Eintrag aus dieser Tabelle, der der Anfrage genügt.
Links und Inodes
Unter QNX können Dateidaten unter mehr als einem Namen angesprochen werden, wobei jeder Dateiname als Link bezeichnet wird. (Es existieren zur Zeit zwei Arten von Links: Hardlinks, welche wir zukünftig einfach als ``Link,'' bezeichnen und symbolische Links. Symbolische Links werden im folgenden beschrieben.)
Um Links für Dateien zu unterstützen, wird der Dateiname von anderen Informationen dieser Datei getrennt aufbewahrt. Die Informationen, die nicht in Verbindung mit dem Dateinamen stehen, werden in einem Inode abgelegt; Abkürzung für ``Information Node, (Informationsknoten)''.
Wenn eine Datei nur einen Link besitzt, (nur einen Dateinamen), werden die Informationen zur Datei selbst im Verzeichniseintrag für diese Datei abgelegt. Hat die Datei jedoch mehr als einen Link, wird der Inode als Record in einer speziellen Datei mit Namen /.inodes abgelegt, als würden die Verzeichniseinträge der Datei zum Inoderecord zeigen.
Beachten Sie, daß Sie nur einen Link auf eine Datei erzeugen können, wenn Link und Datei im gleichen Dateisystem liegen.
Die gleiche Datei wird über zwei Links angesprochen, ``more'' und ``less.''
Es gibt zwei weitere Informationen, bei denen eine Datei einen Eintrag in einer /.inodes Datei erhält:
- Ist der Dateiname der Datei länger als 16 Zeichen, wird die Inodeinformation in einer /.inodes Datei abgelegt, um Platz für einen 48 Zeichen langen Dateinamen im Verzeichniseintrag zu erhalten.
- Hatte eine Datei mehr als einen Link, und wurden alle bis auf einen gelöscht, behält die Datei den gesonderten Eintrag in der /.inodes Datei. Dies wird gemacht, da der Overhead für die Suche eines Verzeichniseintrages, der auf den Inodeeintrag zeigt, zu groß ist (es existiert kein Rückwärtszeiger vom Inode zum Verzeichniseintrag).
| Wenn Sie: | Benutzen Sie: |
|---|---|
| Links aus der Shell heraus erzeugen möchten | das ln Werkzeug |
| Links aus Programmen heraus erzeugen möchten | die link() Funktion |
Links entfernen
Wenn eine Datei erzeugt wird, erhält sie einen Linkzähler mit dem Wert eins. Werden Links hinzugefügt, wird dieser Zähler erhöht. Wird hingegen ein Link gelöscht, wird dieser Zähler verringert. Der Speicherplatz für die Datei selbst wird solange nicht von der Disk gelöscht, bis der Linkzähler den Wert Null erreicht und alle Programme, die diese Datei augenblicklich benutzen, selbige geschlossen haben. Dies macht es möglich, eine Datei weiterhin zu benutzen, obwohl deren Link bereits gelöscht wurde.
| Wenn Sie: | Benutzen Sie: |
|---|---|
| Links von der Shell aus löschen möchten | das rm Werkzeug |
| Links vom Programm heraus löschen möchten | die remove() oder unlink() Funktionen |
Verzeichnislinks
Es können keine Hardlinks auf Verzeichnisse gemacht werden. Jedes Verzeichnis hat zwei fest eingebaute Links:
- . (``Punkt'')
- .. (``Punkt Punkt'')
Der Dateiname ``Punkt'' spezifiziert das momentane Verzeichnis; ``Punkt Punkt'' bezeichnet das Verzeichnis über diesem.
Beachten Sie, daß der ``Punkt Punkt'' Eintrag für ``/'' wiederum ein ``/'' ist - Sie können nicht in das darüberliegende Verzeichnis wechseln.
Symbolische Links
Ein symbolischer Link ist eine spezielle Datei, dessen Daten aus dem Verzeichnisnamen einer Datei besteht. Wird ein symbolischer Link bei einer Ein-/Ausgabe-Anforderung benutzt - zum Beispiel von open() - wird der Linkanteil im Pfad durch die ``Daten'' des Links ersetzt. Danach wird der Pfad erneut aufgelöst. Symbolische Links stellen eine flexible Methode dar, um mehrere Pfade auf ein und dieselbe Datei zu erhalten. Anders als bei Hardlinks können symbolische Links auf andere Dateisysteme und Verzeichnisse verweisen.
Im folgenden Beispiel, verweisen //1/usr/fred und //2/usr/barney auf unterschiedliche Dateisysteme - sie befinden sich auf unterschiedlichen Knoten (siehe folgendes Diagramm). Dies könnte nicht mit Hardlinks erreicht werden:
//1/usr/fred --> //2/usr/barney
Beachten Sie, daß symbolische Links und das Zielverzeichnis nicht notwendigerweise den gleichen Namen haben müssen. In den meisten Fällen benutzen Sie symbolische Links, um ein Verzeichnis durch ein anderes zu referenzieren. Wie auch immer, Sie können natürlich auch symbolische Links für Dateien anwenden; z. B.:
//1/usr/eric/src/test.c --> //1/usr/src/game.c
| Wenn Sie: | Benutzen Sie: |
|---|---|
| symbolische Links erzeugen möchten | ln (mit der -s Option) |
| symbolische Links löschen wollen* | rm |
| prüfen wollen, ob eine Datei ein symbolischer Link ist | ls |
* Beachten Sie, daß das Löschen eines symbolischen Links auf den Link selbst wirkt und nicht auf sein Ziel.
Viele Funktionen arbeiten direkt mit symbolischen Links. Für diese Funktionen wird die Ersetzung des Pfades nicht durchgeführt. Diese Funktionen sind unlink() (welches den symbolischen Link löscht), lstat() und readlink().
Da Links auf Verzeichnisse zeigen können, ist es möglich, Probleme zu erzeugen, wie das zirkuläre Verweisen auf Verzeichniseinträge. Als Schutz gegen solche zirkulären Referenzen benutzt das System eine Wertgrenze für die Anzahl von Etappen für die Auflösung; der Wert ist definiert als SYMLOOP_MAX in der Include-Datei <limits.h>.
Pipes und FIFOs
Pipes
Eine Pipe ist ein namenloser I/O-Kanal zwischen zwei oder mehr kooperierenden Prozessen - ein Prozeß schreibt in die Pipe, ein anderer ließt von ihr. Der Dateisystem-Manager übernimmt dabei die Pufferung der Daten. Die Puffergröße ist definiert als PIPE_BUF in der Include-Datei <limits.h>. Eine Pipe wird gelöscht, wenn ihre beiden Enden geschlossen werden.
Pipes werden normalerweise benutzt, wenn zwei Prozesse gleichzeitig laufen und untereinander Daten in eine Richtung übertragen möchten. (Wenn bidirektionale Kommunikation gefordert ist, sollten stattdessen Nachrichten benutzt werden.)
Eine typische Anwendung für Pipes ist die Verbindung der Ausgabe eines Programmes mit der Eingabe eines anderen. Diese Verbindung wird oft von der Shell benutzt. Zum Beispiel leitet der Befehl:
ls | more
die Ausgabe des ls Werkzeuges an die Standardeingabe des more Werkzeuges.
| Wenn Sie: | Benutzen Sie: |
|---|---|
| Eine Pipe in der Shell erzeugen möchten | das Pipesymbol (``|'') |
| Pipes in einem Programm erzeugen möchten | die pipe() oder popen() Funktionen |
 | Auf plattenlosen Arbeitsplätzen können Sie den Pipe-Manager (Pipe) anstatt des Dateisystem-Managers benutzen. Der Pipe-Manager ist optimiert für Ein-/Ausgabeoperationen im Zusammenhang mit Pipes und hat einen höheren Durchsatz als der Dateisystem-Manager. |
FIFOs
FIFOs sind grundsätzlich das gleiche wie Pipes, mit der Ausnahme, daß FIFOs permanente Dateien mit Namen sind und im Dateisystem gespeichert werden.
| Wenn Sie: | Benutzen Sie: |
|---|---|
| FIFOs aus der Shell heraus erzeugen möchten | das mkfifo Werkzeug |
| FIFOs aus Programmen heraus erzeugen möchten | die mkfifo() Funktion |
| FIFOs von der Shell aus entfernen möchten | das rm Werkzeug |
| FIFOs aus Programmen entfernen möchten | die remove() oder unlink() Funktion |
Dateisystem-Manager-Performance
Der Dateisystem-Manager hat verschiedene vorteilhafte Fähigkeiten, die einen hochperformanten Plattenzugriff ermöglichen:
- Elevator Seeking (Kopfbewegung wie ein Aufzug)
- Puffercache
- Multi-Threading
- clientgetriebene Priorität
- Unterstützung für temporäre Dateien
- RAM-Disks
Elevator Seeking
Das Elevator Seeking minimiert die Positionierzeit der Plattenköpfe, um Daten zu lesen oder auf die Festplatte zu schreiben. Anstehende Ein-/Ausgabeanforderungen werden so umsortiert, daß sie mit einer Kopfbewegung in nur einer Richtung, von der niedrigsten zur höchsten Festplattenadresse, erreicht werden können.
Das Elevator Seeking ermöglicht ebenfalls, daß das Verfahren der Multi-Sektor- Ein-/Ausgabe benutzt werden kann.
Puffercache
Der Puffercache ist ein intelligent verwalteter Speicherbereich zwischen dem Dateisystem-Manager und dem Festplattentreiber. Der Puffercache versucht Blöcke des Dateisystems zu speichern, um die Anzahl der Zugriffe des Dateisystem-Managers auf die Festplatte zu minimieren. Standardmäßig wird die Größe dieses Puffercaches aus der Größe des zur Verfügung stehenden Systemspeichers ermittelt. Sie können die Größe jedoch mit einer Option zum Fsys einstellen.
Leseoperationen werden synchron ausgeführt, Schreiboperationen hingegen können asynchron erfolgen. Wenn die Daten den Cache erreicht haben, antwortet der Dateisystem-Manager einem Clientprozeß unmittelbar, um anzuzeigen, daß die Daten geschrieben wurden. Das Schreiben der Daten auf die Festplatte erfolgt verzögert, sobald es dem Dateisystem-Manager sinnvoll erscheint (typischerweise innerhalb von fünf Sekunden).
Applikationen können das Schreibverhalten auf Dateibasis einstellen. Zum Beispiel kann eine Datenbank alle Schreibvorgänge synchron ausführen lassen. Dies würde mit großer Warscheinlichkeit sicherstellen, daß die Integrität der Datei gewährleistet ist, für den Fall, daß Hardware- oder Stromversorgungsprobleme auftreten.
Multi-Threading
Der Dateisystem-Manager ist ein Prozeß, welcher Multi-Threading benutzt. Dadurch kann er mehrere Ein-/Ausgabeanforderungen simultan bearbeiten. Dies ermöglicht dem Dateisystem-Manager folgende Dinge parallel auszuführen:
- mehrere Geräte parallel anzusprechen
- Ein-/Ausgabeanforderungen aus einem Puffercache zu befriedigen, während andere Ein-/Ausgabeanforderungen auf physikalischen Geräten laufen.
Clientgetriebene Priorität
Der Dateisystem-Manager kann seine eigene Priorität nach der des sendenden Prozesses richten. Empfängt der Dateisystem-Manager eine Nachricht, wird seine eigene Priorität auf die des sendenden Prozesses gesetzt. Für mehr Informationen sehen Sie ``Prozeß-Scheduling'' in Kapitel 2.
Temporäre Dateien
QNX hat eine leistungsfähige Option zum Öffnen von temporären Dateien, welche in kurzer Zeit geschrieben und zurückgelesen werden. Für solche Dateien hält der Dateisystem-Manager die Datenblöcke solange wie möglich im Cache und benutzt die Festplatte nur, wenn es unbedingt nötig ist.
RAM-Disks
Der Dateisystem-Manager besitzt eine integrierte RAM-Disk-Fähigkeit, die es erlaubt, eine bis zu 8 MB große Disk zu simulieren. Da der Dateisystem-Manager das hocheffiziente ``Multipart Messaging'' verwendet, werden die Daten zwischen der RAM-Disk und dem Applikationspuffer direkt transferiert.
Er kann entscheiden, den Puffercache zu umgehen, da die RAM-Disk eingebaut und nicht als Treiber implementiert ist. (Für Informationen zum Multipart Messaging, lesen Sie den Abschnitt "Optimierte Nachrichtenübertragung" in Kapitel 2.)
Da RAM-Disks keine Verzögerungen durch physikalische Hardware erzeugen, und sie außerdem den Dateisystem-Cache nicht belasten, besitzen sie im Allgemeinen ein besseres deterministisches Verhalten für Schreib-/Leseoperationen als Harddisks.
Dateisystem-Robustheit
Das QNX-Dateisystem bringt seinen hohen Durchsatz zustande, ohne Zuverlässigkeit einzubüßen. Dies wird durch unterschiedliche Strategien erreicht.
Während die meisten Daten im Puffercache gehalten werden und erst nach einer kurzen Verzögerung geschrieben werden, können kritische Dateisystemdaten unverzüglich physikalisch geschrieben werden. Aktualisierungen zu Verzeichnissen, Inodes, Erweiterungsblöcken und das Image werden direkt auf die Platte geschrieben, um sicherzustellen, daß die Dateisystemstruktur auf der Platte niemals inkonsistent ist.
Manchmal müssen all die obigen Strukturen aktualisiert werden. Wenn Sie beispielsweise eine Datei in ein Verzeichnis verschieben und die letzte Erweiterung dieses Verzeichnisses voll ist, muß das Verzeichnis erweitert werden. In solchen Fällen wird die Reihenfolge der Abarbeitung so gewählt, daß beim Eintreten eines katastrophalen Fehlers, während die Verarbeitung erst teilweise vollendet ist (z. B. ein Netzfehler), das Dateisystem nach dem Neustart immer noch das ``gleiche'' ist. Im schlimmsten Fall wären einige Blöcke zugeteilt, aber nicht belegt. Diese können Sie für den späteren Gebrauch wieder verwenden, indem Sie das chkfsys Werkzeug laufen lassen.
Wiederherstellung des Dateisystems
Doch selbst in den besten Betriebssystemen kann es zu den folgenden katastrophalen Fehlern kommen:
- Bad blocks (fehlerhafte Blöcke) können sich in Folge von Stromschwankungen oder Stromausfällen auf einer Festplatte entwickeln.
- Ein naiver oder boshafter Benutzer mit Superuserprivilegien könnte das Dateisystem (mit dem dinit Werkzeug) neu initialisieren.
- Ein fehlerhaftes Programm (besonders eines, welches in einer QNX-fremden Umgebung läuft) könnte die Partitionierungsinformationen der Festplatte ignorieren und einen Teil der QNX-Partition überschreiben.
Um so viele Ihrer Dateien wie möglich wiederherstellen zu können, wenn es zu solchen Ereignissen kommt, werden einmalige ``Signaturen'' auf die Festplatte geschrieben, um bei der automatischen Identifikation und dem Wiederherstellen der kritischen Dateisystemteile zu helfen. Die Inodes-Dateien (/.inodes), sowie alle Verzeichnisse und Erweiterungsblöcke, beinhalten einzigartige Datenmuster, welche das chkfsys Werkzeug benutzen kann, um ein zerstörtes Dateisystem wieder zusammenzusetzen.
Weitere Details über das Wiederherstellen von Dateisystemen finden Sie in der Dokumentation des chkfsys Werkzeuges.
Blockorientierte Geräteeinheiten (raw volumes)
Der Dateisystem-Manager verwaltet blockorientierte Dateien. Diese definieren Disks und Diskpartitionen.
Disks und Plattensubsysteme
Für QNX gilt jede physikalische Platte in einem Computer als Block-Spezial-Datei. Als eine Block-Spezial-Datei wird eine Platte von einem QNX-Dateisystem als eine sequentielle Gruppe von Blöcken angesehen, wobei jeder 512 Bytes groß ist, unabhängig von der Größe und Kapazität einer der Platte selbst. Blöcke werden, beginnend mit dem ersten Block auf einer Festplatte (Block 1) von eins an fortlaufend numeriert.
Da jede Platte eine Block-Spezial-Datei ist, kann sie als eine Einheit für einfache Zugriffe von POSIX-C- Funktionen wie open(), close(), read() und write() geöffnet werden. QNX kümmert sich in keinster Weise um irgendwelche Datenstrukturen auf der Platte, da diese als Block-Spezial-Datei definiert wird.
Ein Computer mit QNX kann eine oder mehrere Plattensubsysteme haben. Jedes Plattensubsystem besteht aus einem Controller und einer oder mehreren Platten. Für jedes Plattensubsystem, das vom Dateisystem- Manager verwaltet werden soll, starten Sie einen Gerätetreiber.
Betriebssystem-Partitionen
QNX befolgt die Vorschriften eines de facto Industriestandards, welcher es mehreren Betriebssystemen erlaubt, sich die gleiche physikalische Platte zu teilen. In Anlehnung an diesen Standard kann eine Partitionstabelle bis zu vier primäre Partitionen auf der Platte definieren. Diese Tabelle wird auf dem ersten Block abgelegt.
Jeder Partition muß ein ``Typ'' zugeordnet werden, welcher von dem Betriebssystem, welches diese Partition bearbeiten soll, erkannt wird. Die folgende Liste zeigt einige der momentan genutzen Partitionen:
| Typ | Dateisystem |
|---|---|
| 1 | DOS (12-Bit FAT) |
| 4 | DOS (16-Bit FAT; Partitionen <32MB) |
| 5 | DOS erweiterte Partition |
| 6 | DOS 4.0 (16-Bit FAT; Partitionen >=32MB) |
| 7 | OS/2 HPFS |
| 7 | vorangegangene QNX Version 2 (vor-1988) |
| 8 | QNX 1.x und 2.x ("qny") |
| 9 | QNX 1.x und 2.x ("qnz") |
| 11 | DOS 32-Bit FAT; Partitionen bis zu 2047GB |
| 12 | Wie Typ 11, benutzt aber logische Blockadressenerweiterung Int 13h |
| 14 | Wie Typ 6, benutzt aber logische Blockadressenerweiterung Int 13h |
| 15 | Wie Typ 5, benutzt aber logische Blockadressenerweiterung Int 13h |
| 77 | QNX POSIX Partition |
| 78 | QNX POSIX Partition (sekundäre) |
| 79 | QNX POSIX Partition (sekundäre) |
| 99 | UNIX |
Wenn Sie auf einer physikalischen Platte mehr als eine QNX-4.x-Partition einrichten möchten, würden Sie für Ihre erste QNX-Partition Typ 77, für Ihre zweite Typ 78 und Typ 79 für Ihre dritte Partition wählen. Sie können für die zweite und dritte Partition auch andere Typen wählen, 78 und 79 werden aber bevorzugt. Um einige dieser Partitionen bootfähig zu machen, benutzen Sie das fdisk Werkzeug.
Beim Bootvorgang läßt Sie der QNX-Boot-Loader (optional von fdisk installiert) die Standardbootpartition aus der Partitionstabelle überschreiben, bzw. wählen.
Mit dem fdisk Werkzeug können Sie Partitionen erzeugen, modifizieren oder löschen.
Da QNX jede Partition auf einer Platte als Block-Spezial-Datei behandelt, können Sie auf die folgenden Informationen zugreifen:
- auf die komplette Platte - ungeachtet der darauf befindlichen Partitionen - als eine Block-Spezial-Datei.
- auf eine einzige Partition als Block-Spezial-Datei; diese Block-Spezial-Datei ist eine Unterteilung der Block-Spezial-Datei, welche die gesamte Platte definiert
Zwei physikalische Festplattenlaufwerke. Das erste Laufwerk enthält DOS-, QNX- und UNIX-Partitionen. Das zweite hat DOS- und QNX-Partitionen.
Definition von blockorientierten Dateien
Die Namen aller blockorientierten Dateien werden in den Präfixbaum für den Computer, wo die blockorientierten Dateien sich befinden, abgelegt (der Präfixbaum wird in Kapitel 3, I/O- Namespace, beschrieben). Wenn ein Gerätetreiber für ein Plattensubsystem gestartet wird, registriert der Dateisystem-Manager automatisch Präfixe, welche für jedes an das Plattensubsystem angeschlossene physikalische Laufwerk eine Block-Spezial-Datei definieren. Mit dem mount Werkzeug wird dann ein Präfix für eine Block-Spezial-Datei auf jeder Partition des Plattensubsystemes registriert
Gehen wir beispielsweise davon aus, daß Sie eine Standard-IDE-Schnittstelle haben, an die zwei Laufwerke angeschlossen sind. Auf dem einen Laufwerk möchten Sie eine DOS-Partition, eine QNX-Partition und eine UNIX-Partition mounten. Auf dem anderen Laufwerk möchten Sie eine DOS- und eine QNX-Partition mounten.
Der Dateisystem-Manager würde die blockorientierte Dateien /dev/hd0 und /dev/hd1 für die zwei Laufwerke am Controller definieren, an dem die Laufwerke gestartet wurden.
Um für jede Partition eine Block-Spezial-Datei zu definieren, würden Sie dann das mount Werkzeug benutzen. Zum Beispiel:
mount -p /dev/hd0 -p /dev/hd1
würde die folgenden blockorientierten Dateien erzeugen bzw. anzeigen:
| Betriebssystem Partition: | Block-Spezial-Datei: |
|---|---|
| DOS-Partition auf Laufwerk hd0 | /dev/hd0t4 |
| QNX-Partition auf Laufwerk hd0 | /dev/hd0t77 |
| UNIX-Partition auf Laufwerk hd0 | /dev/hd0t99 |
| DOS-Partition auf Laufwerk hd1 | /dev/hd1t4 |
| QNX-Partition auf Laufwerk hd1 | /dev/hd1t77 |
Beachten Sie, daß die tn Konvention genutzt wird, um auf Plattenpartitionen zu referenzieren, welche durch unterschiedliche Betriebssysteme genutzt werden. Eine DOS-Partition ist zum Beispiel t4, eine UNIX-Partition ist t99, etc.
Ein Dateisystem mounten
Typischerweise wird ein QNX-Dateisystem auf eine Block-Spezial-Datei gemountet. Um ein Dateisystem zu mounten, benutzen Sie erneut das mount Werkzeug - es läßt Sie die Präfixe, welche das Dateisystem identifizieren, spezifizieren. Zum Beispiel:
mount /dev/hd0t77 /
mountet ein Dateisystem mit einem Präfix von / auf die Partition, welche durch die Block-Spezial-Datei hd0t77 definiert wird.
| Wenn eine Platte partitioniert wurde, müssen Sie eine Partition als Block-Spezial-Datei mounten (e.g. /dev/hd0t77, welche eine QNX 4.x Partition definiert, nicht die Basis-Block-Spezial-Datei, welche die gesamte, rohe Platte definiert (z. B. /dev/hd0). Wenn Sie versuchen, die Basis-Block-Spezial-Datei für die gesamte Platte zu mounten, erhalten Sie die Fehlermeldung ``corrupt filesystem'' wenn Sie versuchen, auf das Dateisystem zuzugreifen. |
Ein Dateisystem unmounten
Um den Vorgang des mounten wieder rückgängig zu machen, benutzen Sie das umount Werkzeug. Das folgende Kommando ``unmountet'' zum Beispiel das Dateisystem auf Ihrer primären QNX Partition:
umount /dev/hd0t77
Sobald ein Dateisystem nicht mehr angeschlossen (mounted) ist, kann auf die Dateien auf dieser Partition nicht mehr zugegriffen werden.
Schlüsselkomponenten einer QNX Partition
Verschiedene Schlüsselkomponenten am Anfang jeder QNX Partition bilden zusammen das Dateisystem:
- Ladeblock (loader block)
- Root-Block
- Bitmap
- Root-Verzeichnis
Diese Strukturen werden erzeugt, wenn Sie das Dateisystem mit dem dinit Werkzeug initialisieren.
Struktur eines QNX-Dateisystems innerhalb einer Plattenpartition.
Ladeblock (Loader block)
Der Ladeblock ist der erste physikalische Block einer Plattenpartition. Er enthält den Code, welcher durch das BIOS des Computers geladen und ausgeführt wird, um ein Betriebssystem von der Partition zu laden. Wenn ein Laufwerk nicht partitioniert wurde (z. B. eine Diskette in einem Diskettenlaufwerk), ist dieser Block der erste physikalische Block auf dem Medium.
Root-Block
Der Root-Block ist wie ein Standardverzeichnis strukturiert. Er beinhaltet Inodeinformationen für die folgenden vier speziellen Dateien:
- das Root-Verzeichnis des Dateisystems (/)
- /.inodes
- /.boot
- /.altboot
Die Dateien /.boot und /.altboot enthalten Abbilder des Betriebssystems, welche durch den ``QNX-Bootstrap-Loader'' geladen werden können.
Normalerweise läd der QNX Loader das in der /.boot Datei abgelegte Abbild des Betriebssystems. Existiert aber die /.altboot Datei und ist diese nicht leer, können Sie optional, dessen enthaltenes Abbild laden.
Bitmap
Um Platz auf einer Platte zuzuweisen, benutzt QNX ein Bitmap, welches in der /.bitmap Datei gespeichert ist. Diese Datei beinhaltet einen Lageplan aller Blöcke auf der Festplatte und zeigt an, welche Blöcke benutzt werden. Jeder Block wird durch ein Bit repräsentiert. Ist der Wert eines Bits 1, wird sein korrespondierender Block auf der Platte genutzt.
Root-Verzeichnis
Das Root-Verzeichnis einer Partition verhält sich wie eine normale Verzeichnisdatei, allerdings mit zwei Ausnahmen:
- Sowohl ``Punkt'' als auch ``Punkt Punkt'' sind Links auf dieselbe Inodeinformation, auf den Root-Verzeichnis-Inode des Root-Blocks.
- Das Root-Verzeichnis hat immer Einträge für die /.bitmap, /.inodes, /.boot und /.altboot Dateien. Diese Einträge werden so versorgt, daß Programme, welche Informationen zum Gebrauch des Dateisystems anzeigen, diese Einträge als normale Dateien sehen.
Der DOS-Dateisystem-Manager
In QNX wird der I/O-Namespace durch Präfixe, welche Dateianfragen an den entsprechenden Managerprozeß richten, verwaltet. Ein Prozeß, welcher hieraus Vorteile zieht, ist der DOS-Dateisystem-Manager (Dosfsys). Der Dosfsys administriert den /dos Namespace-Präfix und stellt DOS-Laufwerke innerhalb des QNX-Namespace als ``Gast''-Dateisysteme zur Verfügung.
Der Dosfsys liefert einen transparenten Zugriff auf Dos-Platten. Somit können Sie DOS-Dateisysteme behandeln, als ob es QNX-Dateisysteme wären. Diese Transparenz erlaubt es Prozessen, mit DOS-Dateien, ohne besonderes Wissen über ihre Struktur oder Besonderheiten, zu operieren. Standard Ein-/Ausgabe-Bibliotheksfunktionen, wie open(), close(), read() und write(), verhalten sich zu einer Datei auf einer DOS-Partition wie für eine Datei auf einer QNX-Partition identisch. Um zum Beispiel eine Datei von einer QNX-Partition auf eine DOS-Partition zu kopieren, müssen Sie lediglich das folgende eingeben:
cp /usr/luc/file.dat /dos/c/file.dat
Beachten Sie, daß /dos/c den Pfadnamen des DOS-Verzeichnisses C beschreibt. Das cp Kommando beinhaltet keinen besonderen Code, um festzustellen, ob die Datei, die es kopiert, an eine DOS-Platte gerichtet ist. Andere Kommandos arbeiten mit ähnlicher Transparenz (z. B. cd, ls, mkdir).
Wenn es unter DOS kein Equivalent zu einem QNX-Feature, wie mkfifo() oder link(), gibt, wird ein entsprechender Fehlercode (z. B. errno) von dem Dosfsys zurückgegeben.
Der Dosfsys arbeitet sowohl mit Floppy- als auch mit Festplatten-Partitionen. Der gesamte Plattenzugriff, den der Dosfsys benötigt, wird durch Standardfunktionen, welche der Dateisystem-Manager liefert, erledigt. Somit ist der Dosfsys in der Lage, eine nahtlose Verbindung zwischen QNX-Applikationen und einem DOS-Dateisystem zu integrieren.
CD-ROM-Dateisystem
Das CD-ROM-Dateisystem, Iso9660fsys, bietet transparenten Zugriff auf CD-ROM-Medien. Somit können Sie CD-ROM-Dateisysteme behandeln, als ob sie POSIX-Dateisysteme wären. Diese Transparenz erlaubt Prozessen mit CD-ROM-Dateien zu arbeiten, ohne spezielles Wissen über dessen Struktur zu benötigen.
Iso9660fsys implementiert den ISO 9660 Standard, inklusive Rock-Ridge-Erweiterungen. DOS- und Windows-CDs folgen diesem Standard. In Anlehnung an normale Dateien, unterstützt Iso9660fsys auch Audio.
Flash
Der Flash-Dateisystem-Manager, Efsys.*, wurde explizit entworfen, um mit Flash Speicher zu arbeiten, sowohl für auswechselbare als auch für nicht auswechselbare Medien. Dateien, die auf bewegliche Flash Medien geschrieben werden (PC-Karten), sind auf andere Systeme, welche den gleichen Standard unterstützen, portierbar.
Der Efsys.* kombiniert die Funktionen eines Dateisystem- Managers und eines Gerätetreibers, um ein Flash-Dateisystem auf speicherbasierenden Medien zu verwalten. Weil der Efsys.* die Gerätetreiber zur Hardwarekontrolle beinhaltet, existieren verschiedene Versionen des Efsys.* für unterschiedliche Embedded-Systemhardware. Zum Beispiel:
- Efsys.explr2 für das Intel EXPLR2 Evaluation Bord (mit on-bord RFA)
- Efsys.elansc400 für das AMD Élan SC400 Evaluation Bord
- Efsys.pcmcia für den gemischten Gebrauch von Flash Dateisystemen und PCMCIA Geräten
Restriktionen
Die Funktionalität des Dateisystems wird durch die eingesetzten Speichergeräte beschränkt. Beinhaltet das Medium zum Beispiel nur ROM-Geräte, kann von dem Dateisystem nur gelesen werden.
Speicherbasierende Flash-Geräte sind beim Schreiben von Dateien eingeschränkt. Sie können der Datei lediglich etwas hinzufügen. In Anlehnung daran werden Datei-Zugriffszeiten nicht aktualisiert. Diese Restriktionen gelten ebenfalls, wenn Geräte wie SRAM eingesetzt werden.
Space-Reklamation
Der Efsys.* speichert Verzeichnisse und Dateien, indem er verzeigerte Listen von Datenstrukturen gebraucht, im Gegensatz zu Blöcken mit fester Größe, wie es bei traditionellen Dateisystemen mit rotierenden Medien der Fall ist. Wenn ein Verzeichnis oder eine Datei gelöscht wird, werden die Datenstrukturen, welche das Verzeichnis oder die Datei repräsentieren zwar als gelöscht markiert, aber nicht entfernt. Dadurch wird kontinuierliches Löschen von und Schreiben auf das Medium verhindert.
Eventuell ist das Medium irgendwann voll und der Dateisystem-Manager wird eine sogen. Speicherplatzreklamation durchführen (a.d.Ü. "Garbage collection"). Während dieses Prozesses stellt der Efsys.* den durch gelöschte Verzeichnisse und Dateien belegten Platz wieder zur Verfügung. Um eine Speicherplatzreklamation durchzuführen, benötigt der Dateisystem-Manager mindestens einen übergebliebenen Block auf dem Medium. Das mkffs Werkzeug reserviert automatisch einen solchen Block, wenn Sie ein Dateisystem erzeugen.
Komprimierung und Dekomprimierung
Der Efsys.* unterstützt Dekomprimierung, wodurch die Datenmenge, welche auf einem Medium abgelegt werden kann, vergrößert wird, wobei die Dekomprimierung für die Applikation transparent abläuft.
Um Dateien durch den Dateisystem-Manager transparent zu komprimieren, müssen Sie sie vorab explizit komprimieren, bevor Sie das mkffs Kommando benutzen. Das Werkzeug dafür ist das bpe. Wenn Sie eine komprimierte Datei in ein aktives Flash-Dateisystem kopieren, bleibt diese komprimiert, wenn sie vom Dateisystem wieder gelesen wird.
Dateiberechtigungen
Wenn Sie die POSIX-Erweiterungen abschalten, werden die Dateibesitzrechte permanent auf Root und alle Berechtigungen auf rwx gesetzt. Die Kommandos chgrp, chmod und chown funktionieren nun nicht mehr.
Mounten
Mountpunkte können Sie nur setzen, wenn Sie Partitionen initialisieren oder wenn Sie den Dateisystem-Manager starten.
Direktzugriff auf Gerätedateien
Wenn Sie den Efsys.* starten, erzeugt er für jedes Medium eine besondere Gerätedatei im /dev Verzeichnis. In einem System mit zwei speicherbasierenden Medien wären diese besonderen Dateien /dev/skt1 und /dev/skt2. Das spezielle Gerät ignoriert die Partitionierung und läßt einen ``raw device access'' auf das Medium zu.
Eine Dateisystem-Partition kann nur als ``raw device'' angesprochen werden. Für jede Partition eines Dateisystems erzeugt der Efsys.* eine besondere Datei in dem Format /dev/sktXimgY, wobei X die Socket-Nummer des Mediums ist und Y für die Nummer der Dateisystem-Partition auf diesem Medium steht.
NFS-Dateisystem
Das Netzwerkdateisystem (Network File System, NFS) ist eine TCP/IP-Applikation, welche ursprünglich von Sun Microsystems entwickelt wurde. Inzwischen ist NFS in die meisten DOS- und UNIX-Systeme implementiert worden. Für den transparenten Zugriff auf Dateisysteme anderer Betriebssysteme, welche NFS unterstützen, werden sie die QNX Implementation schätzen.
| QNX unterstützt vernetzte Dateisysteme schon durch seine Architektur. NFS müssen Sie nur dann einsetzen, wenn Sie auf andere NFS-Dateisysteme als die von QNX zugreifen oder Sie NFS-Clients den Zugriff auf Ihren QNX-Namespace ermöglichen müssen. |
NFS läßt Sie entfernte Dateisysteme - oder Teile von ihnen - in Ihren lokalen Namespace einbetten. Verzeichnisse auf den entfernten Systemen erscheinen wie ein Teil Ihres lokalen Dateisystems und alle Werkzeuge, die Sie für die Auflistung und Verwaltung von Dateien benutzen (z. B. ls, cp, mv) arbeiten auf den entfernten Dateien genauso wie auf Ihren lokalen Dateien.
| In QNX 4 benötigt NFS den Socket Manager, welcher die in TCP/IP benutzten Netzwerkprotokolle für QNX implementiert. Beachten Sie, daß eine "leichtere" Version des Socket- Managers, der Socklet, ebenfalls verfügbar ist, wenn Sie NFS nicht benötigen. |
SMB-Dateisystem
Das SMBfsys implementiert das SMB (Server Message Block) Protokoll zum gemeinsamen Zugriff auf Dateien. Dieses Protokoll wird von verschiedenen Servern wie Windows NT, Windows 95, Windows for Workgroups, LAN-Manager und Samba benutzt. SMBfsys erlaubt einem QNX-Client transparent auf entfernte Laufwerke auf solchen Servern zuzugreifen.
Das SMBfsys implementiert dieses Protokoll, indem es in TCP/IP nur NetBIOS, nicht NetBEUI, nutzt. Dementsprechend müssen Sie TCP/IP sowohl auf QNX als auch auf dem entfernten Server installieren. Sobald SMBfsys läuft und ein entfernter Server gemountet wurde, erscheint das Dateisystem des Servers in der lokalen Verzeichnisstruktur.