DE69601850T2

DE69601850T2 - Transaktionsgerättreiberverfahren für ein Dateiensystem mit Logging-Möglichkeit

Info

Publication number: DE69601850T2
Application number: DE69601850T
Authority: DE
Inventors: Billy J. Fuller
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-09-11
Filing date: 1996-09-04
Publication date: 1999-10-14
Anticipated expiration: 2016-09-05
Also published as: DE69601850D1; US5778168A; EP0767435B1; EP0767435A1; JPH09114718A

Description

Die vorliegende Erfindung bezieht sich auf das Objekt der EP-A-762302.

HINTERGRUND DER ERFINDUNG

Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der Dateisysteme ("FS") von Computerbetriebssystemen ("OS"). Genauer bezieht sich die vorliegende Erfindung auf einen Transaktionsgerätetreiber für ein Journal- Dateisystem, um die Unteilbarkeit von Schreiboperationen in eine Computermassenspeichervorrichtung im Fall eines Systemausfalls sicherzustellen.
Da Computermassenspeichervorrichtungen wie z. B. Plattenlaufwerke die Unteilbarkeit von Daten nicht garantieren können, wenn ein Systemausfall während einer "Schreib"- Operation auftreten sollte, müssen herkömmliche Journal- Dateisysteme komplexe Transaktionsmechanismen verwenden, um dies zu kompensieren. Ein Systemausfall während einer Plattenschreiboperation führt üblicherweise zu einer nicht deterministischen Mischung alter und neuer Daten, die auf die Platte geschrieben worden sind und anschließend beim Neustart des Computersystems gelesen werden. Es wäre daher sehr wünschenswert, wenn die Unteilbarkeit der Daten garantiert werden könnte, ohne daß die Implementierung verschiedener komplexer Transaktionsmechanismen nötig wäre.
US-A-5.414.840 offenbart ein Verfahren und ein System zum Verringern der Wiederherstellungszeit für fehlgeschlagene unteilbare Transaktionen, indem Kopien der geänderten Steuerdatenstrukturen im Hauptspeicher gehalten werden.
Alle Benutzer können Daten gemeinsam nutzen, die aus einer Datenbank auf Plattenbasis gelesen werden, wobei die gelesenen Daten anschließend in einem Puffer-Pool gespeichert werden. Im Betrieb wird ein "Vorher"-Abbild jeder laufenden unteilbaren Transaktion in einem Speicherlogbuch gehalten. Das heißt, ein "Vorher"-Abbild der Daten, die im Logbuch geändert werden sollen. Nur nach einem Prozeßausfall wird dieses "Vorher"-Abbild verwendet, um die Daten in einen konsistenten Zustand zurückzuversetzen. Ein Wiederherstellungsprozeß liest die Wiederherstellungsdaten (d. h. er liest das "Vorher-Abbild oder die vorherigen Daten) aus einer Wiederherstellungsstruktur und plaziert diese in einer Steuerstruktur. Die Steuerstruktur wird somit in ihrem vorherigen Zustand rekonstruiert, wobei mittels der somit intakten Steuerstruktur die im Puffer-Pool gehaltenen Daten gültig bleiben.

ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung schafft ein Verfahren und ein Computersystem zum Sicherstellen der Unteilbarkeit der modifizierten Daten, die in eine Computermassenspeichervorrichtung geschrieben werden oder aus dieser gelesen werden, in einer Transaktion in Verbindung mit einem Computerbetriebssystem, das ein Logbuchdateisystem besitzt, gemäß den folgenden Ansprüchen 1 und 7.
Die Transaktionsgerätetreibertechnik für ein Logbuchdateisystem der vorliegenden Erfindung ist von besonderer Nützlichkeit beim Sicherstellen der Unteilbarkeit von Schreiboperationen in eine Computermassenspeichervorrichtung im Fall eines Systemausfalls, indem eine Transaktionsschnittstelle exportiert wird, die auf die Anforderungen der herkömmlichen Logbuchdateisysteme zugeschnitten ist. In einer bestimmten hier offenbarten Ausführungsform informiert das US-Dateisystem den Transaktionsgerätetreiber, wenn eine Dateisystemoperation beginnt und endet. Während der Operation informiert das Dateisystem den Transaktionstreiber ferner über wichtige Datenaktualisierungen, die seit dem Beginn der Dateisystemoperation aufgetreten sind. Der hier offenbarte Transaktionsgerätetreiber verfolgt die Aktualisierungen, wenn die Daten erscheinen, durch die normalen Lese/Schreib/Strategieeinsprungpunkte in den Treiber.
Sollte das System ausfallen, während ausstehende Operationen vorliegen, stellt der Transaktionsgerätetreiber dann sicher, daß entweder alle Änderungen für die Operation im Dateisystem erscheinen, oder daß keine der Änderungen erscheint. Folglich sind die Daten, die auf die Platte geschrieben worden sind und beim Neustart gelesen werden, entweder alles neue Daten oder alles alte Daten, ohne nicht deterministische Mischung der beiden.
Unter den Vorteilen des hier offenbarten Transaktionsgerätetreibers ist die Tatsache, daß die offenbarte Logbuchfunktionalität einem UNIX®-OS-Dateisystem oder einem verwandten OS-Dateisystem leicht hinzugefügt werden kann, wobei bestehende Codewege intakt bleiben, jedoch einige Aufrufe zum Transaktionsgerätetreiber hinzugefügt werden. In einer bestimmten Ausführungsform ist der zusätzliche Transaktionscode außerdem relativ lokalisiert, um die Wartung und die Testfunktionen zu verbessern. Außerdem werden keine neuen Interaktionen zwischen dem Dateisystem-Untersystem, dem virtuellen Speicheruntersystem und dem Plattenpuffer-Cache-Untersystem eingeführt, wodurch die Leistungsfähigkeit, die Stabilität und die Wartungsfähigkeit verbessert werden. Schließlich können die Hilfsmittel, die auf dem Dateisystem aufbauen, unverändert bleiben. Ohne den Transaktionsgerätetreiber der vorliegenden Erfindung müßten herkömmliche Hilfsmittel wie z. B. die Dateisystemprüfung ("fsck"), "dump" und "quotacheck" sowohl das Dateisystem als auch das Logbuch des Dateisystems oder das Logbuch verarbeiten.
Die vorliegende Erfindung wird teilweise implementiert durch Hinzufügen eines Journals oder Logbuches zum OS- Dateisystem, das ein beliebiges System-V-Basis-UNIX®-OS mit einer UFS-Schicht oder einem Äquivalent, das IBM-AIX® oder Microsoft-Windows-NTTM-Betriebssysteme enthält. Das Journal enthält Sequenzen von Dateisystemaktualisierungen, die in unteilbare Transaktionen gruppiert sind, und wird gemanagt mit einem neuen Typ von Metavorrichtung, der Metatrans-Vorrichtung. Das Hinzufügen eines Journals zum Betriebssystem bewirkt schnellere Neustarts und schnelle synchrone Schreibvorgänge (wie z. B. Netzdateisystem-("NFS")-Aktualisierungen, O_SYNC- und Verzeichnisaktualisierungen).
In der hier offenbarten speziellen Ausführungsform ist die vorliegende Erfindung vorteilhaft als eine Erweiterung des UFS-Dateisystems implementiert, das durch die Verwendung eines Logbuches schnellere synchrone Operationen und schnellere Neustartvorgänge bietet. Dateisystemaktualisierungen werden im Logbuch sicher aufgezeichnet, bevor sie am Dateisystem selbst vorgenommen werden. Der Entwurf kann in entsprechenden oberen und unteren Schichten implementiert sein. In der oberen Schicht wird das UFS-Dateisystem mit Aufrufen an die untere Schicht modifiziert, die Dateisystemaktualisierungen aufzeichnet. Die untere Schicht umfaßt eine Pseudovorrichtung, die Metatrans-Vorrichtung, und ist verantwortlich für das Management der Inhalte des Logbuches.
Die Metatrans-Vorrichtung umfaßt zwei Untervorrichtungen, die Logbuchführungsvorrichtung und die Master-Vorrich tung. Die Logbuchführungsvorrichtung enthält das Logbuch der Dateisystemaktualisierungen, während die Master- Vorrichtung das Dateisystem selbst enthält. Die Existenz einer separaten Logbuchführungsvorrichtung ist für den Benutzerprogrammcode und für einen Großteil des Kerns unsichtbar. Die Metatrans-Vorrichtung stellt herkömmliche Block- und Roh-Schnittstellen zur Verfügung und verhält sich ähnlich wie eine gewöhnliche Plattenvorrichtung.
Unter Verwendung herkömmlicher OS-Lösungsansätze müssen die Dateisysteme geprüft werden, bevor sie verwendet werden, da das Herunterfahren des Systems Systemaufrufe unterbrechen kann, die in Arbeit sind, und somit Inkonsistenzen hervorrufen kann. Das Einbinden (mounting) eines Dateisystems, ohne dieses zuerst zu prüfen und irgendwelche Inkonsistenzen zu reparieren, kann "Paniken" oder eine Datenkorruption hervorrufen. Das Prüfen ist bei großen Dateisystemen eine relativ langsame Operation, da es das Lesen und Prüfen der Dateisystem-Metadaten erfordert. Unter Nutzung der vorliegenden Erfindung müssen die Dateisysteme zum Neustartzeitpunkt nicht geprüft werden, da die Änderungen von unvollendeten Systemaufrufen verworfen werden. Als Folge hiervon wird sichergestellt, daß die Dateisystemdatenstrukturen auf der Platte immer konsistent bleiben, d. h. daß sie keine ungültigen Adressen oder Werte enthalten. Die einzige Ausnahme ist, daß freier Raum vorübergehend verloren gehen kann, wenn das System abstürzt, während geöffnete, jedoch nicht verknüpfte Dateien ohne Verzeichniseinträge vorhanden sind. Ein Kernvorgang beansprucht diesen Raum möglicherweise neu.
Die vorliegende Erfindung verbessert ferner die synchrone Schreibleistung durch Reduzieren der Anzahl der Schreiboperationen und durch Beseitigen der Plattensuchzeit. Die Schreibvorgänge sind kleiner, da im Logbuch Deltas aufge zeichnet werden, statt ganze Dateisystemblöcke neu zu schreiben. Außerdem gibt es weniger Blöcke, da verwandte Aktualisierungen zu einer einzelnen Schreiboperation zusammengefaßt werden. Die Plattensuchzeit wird erheblich reduziert, da Schreibvorgänge in das Logbuch sequentiell sind.
Wie hier mit Bezug auf eine spezielle Ausführungsform der Vorliegenden Erfindung beschrieben worden ist, kann das UFS-Plattenformat beibehalten werden, wobei keine Änderungen erforderlich sind, um die Logbuchführung einem bestehenden UFS-Dateisystem hinzuzufügen, wobei das Logbuch anschließend entfernt werden kann, um zum Standard-UFS zurückzukehren. Außerdem funktionieren UFS- Hilfsmittel weiterhin wie vorher, wobei Dateisysteme zum Startzeitpunkt nicht auf Konsistenz geprüft werden müssen. Der Treiber muß das Logbuch abtasten und seinen internen Zustand wiederherstellen, um irgendwelche abgeschlossenen Transaktionen, die hier aufgezeichnet sind, widerzuspiegeln. Die für das Abtasten des Logbuchs aufgewendete Zeit hängt von der Größe der Logbuchvorrichtung ab, jedoch nicht von der Größe des Dateisystems. Für vernünftige, vorhersehbare Konfigurationswahlmöglichkeiten können Abtastzeitspannen von im Mittel 1 bis 10 s pro Gigabyte der Dateisystemkapazität akzeptiert werden.
NFS-Schreibvorgänge und Schreibvorgänge in Dateien, die mit O_SYNC geöffnet worden sind, sind schneller, da Dateisystemaktualisierungen zusammengefaßt werden und sequentiell in die Logbuchführungsvorrichtung geschrieben werden. Dies bedeutet weniger Schreibvorgänge und eine deutlich reduzierte Suchzeit. Eine signifikant verbesserte Beschleunigung kann erwartet werden auf Kosten eines um ungefähr 50% höheren Zentraleinheit-("CPU")- Aufwands. Ferner sind NFS-Verzeichnisoperationen schneller, da Dateisystemaktualisierungen zusammengefaßt werden und sequentiell in die Logbuchführungsvorrichtung geschrieben werden. Lokale Operationen sind ebenfalls schneller, da die Logbuchführung von Aktualisierungen optional bis zu einem sync(), einem fsync() oder einer synchronen Dateisystemoperation verzögert werden können. Wenn keine Logbuchführungsvorrichtung vorhanden ist, können die Verzeichnisoperationen wie üblich synchron abgeschlossen werden.
Wenn ein Stromausfall auftritt, während ein Schreibvorgang in die Master- oder Logbuchführungsvorrichtung durchgeführt wird, sind die Inhalte des letzten geschriebenen Plattensektors unvorhersehbar und können sogar unlesbar sein. Das Logbuch der vorliegenden Erfindung ist so ausgelegt, daß keine Dateisystem-Metadaten unter diesen Umständen verloren gehen. Das heißt, das Dateisystem bleibt im Fall von Stromausfällen konsistent. In der hier genau beschriebenen speziellen Ausführungsform können die Benutzer die Metatrans-Vorrichtung einrichten und verwalten, indem sie Standard-MDD-Hilfsmittel verwenden, wobei die Befehle metainit(lm), metaparam(lm) und metastat(lm) kleine Erweiterungen besitzen. Der Gebrauch ist daher vereinfacht, da keine neuen Schnittstellen erlernt werden müssen und die Master-Vorrichtung und die Logbuchführungsvorrichtung sich gemeinsam wie ein Einzelplattenlaufwerk verhalten. Außerdem kann die gleiche Logbuchführungsvorrichtung gleichzeitig von mehreren UFS- Dateisystemen verwendet werden. Dies vereinfacht in einigen Situationen die Systemverwaltung.
Bei herkömmlichen UFS-Implementierungen belegt das Dateisystem eine Plattenpartition und der Dateisystemcode führt Aktualisierungen durch, indem er Lese- und Schreibbefehle an den Gerätetreiber für die Platte ausgibt. Mit der Erweiterung der vorliegenden Erfindung kann die Dateisysteminformation in einer logischen Vorrichtung gespeichert werden, die eine Metatrans-Vorrichtung genannt wird, wobei in diesem Fall der Kern mit dem Metatrans-Treiber anstatt mit einem Plattentreiber kommuniziert. Bestehende UFS-Dateisysteme und Vorrichtungen können ohne Änderung weiter verwendet werden.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Die obenerwähnten und weitere Merkmale und Aufgaben der vorliegenden Erfindung, sowie die Art, diese zu erreichen, werden deutlicher und die Erfindung selbst wird besser verstanden mit Bezug auf die folgende Beschreibung einer bevorzugten Ausführungsform in Verbindung mit den beigefügten Zeichnungen, in welchen:
Fig. 1 eine vereinfachte Darstellung eines Universalcomputers ist, der einen Teil der Betriebsumgebung der vorliegenden Erfindung bildet;
Fig. 2 eine vereinfachte Darstellung ist, die einen architektonischen Überblick darüber bietet, wie ausgewählte Elemente des Computerprogramms für die Bewerkstelligung einer repräsentativen Implementierung der vorliegenden Erfindung mit verschiedenen Schichten und Schnittstellen eines Computerbetriebssystems in Wechselwirkung treten;
Fig. 3 eine genauere Darstellung der Hauptfunktionskomponenten des Computerprogramms der Fig. 2 ist, die die Komponenten der Metatrans-Vorrichtung und ihre Wechselwirkung über die VOP- oder VFS-Schnittstelle eines System-V-Basis-Computerbetriebssystems gemäß der im folgenden beschriebenen beispielhaften Ausführungsform genauer zeigt;
Fig. 4 ein vereinfachtes logisches Blockschaltbild ist, das die Tatsache zeigt, daß die Einheitsstruktur für die Metatrans-Vorrichtungen die Adresse der Logbuchführungsvorrichtungseinheitsstruktur enthält, und umgekehrt;
Fig. 5 ein zusätzliches vereinfachtes logisches Blockschaltbild ist, das die Tatsache zeigt, daß die Einheitsstrukturen der Logbuchführungsvorrichtung in einer globalen verknüpften Liste erhalten bleiben, die mittels einer ul_list verankert ist, und daß jede der Metatrans- Einheitsstrukturen für die Metatrans-Vorrichtungen, die eine Logbuchführungsvorrichtung gemeinsam nutzen, in einer verknüpften Liste gehalten wird, die mittels der Einheitsstruktur der Logbuchführungsvorrichtung verankert ist;
Fig. 6 ein weiteres vereinfachtes logisches Blockschaltbild ist, das zeigt, daß die Logbuchabbildung einen mapentry_t für jedes Delta im Logbuch enthält, das in die Master-Vorrichtung gerollt werden muß, wobei die Abbildungseinträge von (metatrans dev, metatrans device offset) gesammelt und in einer verknüpften Liste in der Reihenfolge gehalten werden, in der sie hinein gerollt werden sollen;
Fig. 7 ein vereinfachtes logisches Blockschaltbild ist, das zeigt, daß die Einheitsstrukturen für die Metatrans- Vorrichtung und die Logbuchführungsvorrichtung die Adresse für die Logbuchabbildung enthalten;
Fig. 8 ein zusätzliches vereinfachtes logisches Blockschaltbild ist, das die Tatsache zeigt, daß eine Deltaabbildung jeder Metatrans-Vorrichtung zugeordnet ist und die Informationen bezüglich der Änderungen speichert, die eine Dateisystemoperation enthalten, wobei die Metatrans- Vorrichtung einen Abbildungseintrag für jedes Delta erzeugt, das in der Deltaabbildung gespeichert ist;
Fig. 9 ein weiteres vereinfachtes logisches Blockschaltbild ist, das zeigt, daß am Ende einer Transaktion der mit jedem Abbildungseintrag aufgezeichnete Rückruf aufgerufen wird, wobei die Logbuchabbildungsschicht die Delta- Plus-Daten im Schreibpuffer des Logbuches speichert und die Abbildungseinträge in die Logbuchabbildung einsetzt;
Fig. 10 ein vereinfachtes logisches Blockschaltbild ist, das zeigt, daß die Logbuchabbildung ferner für Leseoperationen verwendet wird, wobei dann, wenn der gelesene Puffer nicht mit irgendeinem der Einträge in der Logbuchabbildung überlappt, die Leseoperation zur Master- Vorrichtung hinuntergereicht wird, während ansonsten die Daten für den Puffer eine Kombination aus Daten von der Master-Vorrichtung und aus Daten von der Logbuchführungsvorrichtung sind;
Fig. 11 zeigt, daß früh im Neustartprozeß jede Metatrans- Vorrichtung sich selbst mit der UFS-Funktion ufs_trans_set aufzeichnet, eine ufstrans-Struktur erzeugt und diese in eine global verknüpfte Liste einbindet;
Fig. 12 ferner zeigt, daß zum Einbindungs-Zeitpunkt das Dateisystem sein dev_t mit den anderen dev_t, die in den ufstrans-Strukturen gespeichert sind, vergleicht und dann, wenn eine Übereinstimmung vorliegt, das Dateisystem die Adresse der ufstrans-Struktur in seiner dateisystemspezifischen per-mount-Struktur (ufsvfs) zusammen mit ihrer generischen per-mount-Struktur (vfs) in der ufstrans-Struktur speichert; und
Fig. 13 eine zusätzliche Darstellung der Schnittstelle zwischen dem Betriebssystemkern und dem in den vorange henden Figuren gezeigten Metatrans-Treiber ist, die zeigt, daß das Dateisystem mit dem Treiber kommuniziert durch Aufrufen von Einsprungpunkten in der ufstransops- Struktur, einschließlich der begin-Operation, der end- Operation und der record-delta-Funktion.

BESCHREIBUNG EINER BEVORZUGTEN AUSFÜHRUNGSFORM

Die Umgebung, in der die vorliegende Erfindung verwendet wird, umfaßt ein allgemein verteiltes Rechnersystem, in welchem Universalcomputer, Arbeitsstationen oder Personalcomputer über Kommunikationsverbindungen verschiedener Typen in einer Client-Server-Anordnung verbunden sind, in der Programme und Daten, viele in Form von Objekten, mittels verschiedener Elemente des Systems zur Ausführung und für einen Zugriff mittels anderer Elemente des Systems verfügbar gemacht werden. Einige der Elemente eines Universal-Arbeitsplatz-Computers sind in Fig. 1 gezeigt, in der ein Prozessor 1 gezeigt ist, der einen Eingabe/Ausgabe-("E/A")-Abschnitt 2, eine Zentraleinheit ("CPU") 3 und einen Speicherabschnitt 4 besitzt. Der E/A- Abschnitt 2 ist mit einer Tastatur 5, einer Anzeigeeinheit 6, einer Plattenspeichereinheit 9 und einer Compakt- Disc-Nur-Lese-Speicher-("CDROM")-Laufwerkseinheit 7 verbunden. Die CDROM-Einheit 7 kann ein CDROM-Medium 8 lesen, das typischerweise Programme 11 und Daten enthält. Die Computerprogrammprodukte enthalten Mechanismen zum Betätigen der Vorrichtung, wobei Verfahren der vorliegenden Erfindung im Speicherabschnitt 4 oder auf einer Plattenspeichereinheit 9 oder auf der CDROM 8 eines solchen Systems enthalten sein können.
In Fig. 2 ist eine vereinfachte Darstellung der Architektur 20 zum Implementieren der vorliegenden Erfindung in Verbindung mit z. B. einem System-V-Basis-UNIX-Betriebssystems mit einer Benutzerschicht 22 (oder Systemaufruf schicht) und einem Kern 24 gezeigt. Mit Modifizierungen an Abschnitten der Benutzerschicht 22 (d. h. den MDD3- und Einbindungs-Hilfsmitteln 28) und am Kern 24 (d. h. der UFS-Schicht 30), wie im folgenden genauer beschrieben wird, wird die vorliegende Erfindung hauptsächlich implementiert durch Zusätze zur Metatrans-Schicht 26 in Form eines Metatrans-Treibers 32, einer Transaktionsschicht 34, eines Rollcodes 36, eines Wiederherstellungscodes 38 und eines zugehörigen Logbuch-Codes (oder Journal-Codes) 40.
Die MDD3-Hilfsmittel verwalten den Metatrans-Treiber 32 und richten dessen Status ein, ziehen denselben herunter und geben diesen vor. Die Einbindungs-Hilfsmittel enthalten ein neues Merkmal ("-syncdir"), das das Merkmal der verzögerten Verzeichnisaktualisierungen sperrt. Die UFS- Schicht 30 kommuniziert mit dem Metatrans-Treiber 32 beim Einbinden, Auskoppeln (unmounting) und wenn Dateisystem- Systemaufrufe bedient werden. Der primäre Metatrans- Treiber 32 kommuniziert mit dem Basis-MDD3-Treiber, wobei die Transaktionsschicht 34 mit dem primären Metatrans- Treiber 32 und mit der UFS-Schicht 30 kommuniziert. Der Rollcode 36 rollt abgeschlossene Transaktionen zur Master-Vorrichtung und befriedigt ferner eine Leseanfrage durch Kombinieren von Daten aus den verschiedenen Stücken des Metatrans-Treibers 32. Der Wiederherstellungscode tastet das Logbuch ab und erstellt die Logbuchabbildung neu, wie im folgenden genauer beschrieben wird, während der Logbuchcode die oberen Schichten des Betriebssystems mit einer Bytestromvorrichtung darstellt und Partial- Plattenlaufwerk-Schreiboperationen erfaßt.
In Fig. 3 sind die Hauptkomponenten der Architektur der vorliegenden Erfindung genauer gezeigt. Die UFS-Schicht 30 wird über die VOP- oder VFS-Schnittstelle 42 erreicht. Die UFS-Schicht 30 wechselt das Dateisystem durch Ändern der In-Kern-Kopien der Daten des Dateisystems. Die In- Kern-Kopien werden im Puffer oder im Seiten-Cache 41 gehalten. Die Änderungen an den In-Kern-Kopien werden als Deltas 43 bezeichnet. Das UFS teilt dem Metatrans-Treiber 32 mit, welche Deltas 43 wichtig sind, in dem es die transops-Schnittstelle 45 zur Metatrans-Vorrichtung 32 verwendet.
Die UFS-Schicht erzwingt nicht nach jedem Delta 43 einen Schreibvorgang. Dies wäre ein erheblicher Leistungsverlust. Statt dessen werden die geänderten Puffer und Seiten durch eine normale Systemaktivität oder durch ITS am Ende eines Aufrufs der VOP- oder VFS-Schnittstelle 42 geschoben, der die Deltas 43 verursacht hat. Wie schematisch gezeigt, sieht der Metatrans-Treiber 32 für die oberen Schichten des Kerns 24 wie ein Einzelplattenlaufwerk aus. Intern umfaßt der Metatrans-Treiber 32 zwei Plattenvorrichtungen, die Master- und Logbuchvorrichtungen 44, 46. Schreibvorgänge in die Metatrans-Vorrichtung 32 werden entweder über bdev_strategy zur Master-Vorrichtung 44 weitergeleitet oder, wenn die Deltas 43 entgegen der Anfrage über die transops-Schnittstelle 45 aufgezeichnet worden sind, es werden die geänderten Abschnitte der Daten in einen Schreibpuffer 50 und in einen zugehörigen Logbuchraum kopiert und die Anfrage wird E/A-behandelt. Die Deltas 43 werden von der Deltaabbildung 48 in diesem Prozeß zur Logbuchabbildung 54 bewegt. Der Schreibpuffer 50 wird in die Logbuchvorrichtung 46 geschrieben, wenn ITS ein (nicht gezeigtes) commit am Ende eines Aufrufs der VOP- oder VFS-Schicht 42 ausgibt oder wenn der Schreibpuffer 50 gefüllt ist. Einige Transaktionen, wie z. B. Nachschlagvorgänge oder Schreibvorgänge in Dateien, die nicht O_SYNC geöffnet sind, werden im Schreibpuffer 50 als eine einzelne Transaktion einfach gesammelt.
Das Lesen der Metatrans-Vorrichtung 32 ist etwas kompliziert, da die Daten für das Lesen aus irgendeiner Kombination der Schreibpuffer 50, Lesepuffer 52, der Master- Vorrichtung 44 und der Logbuchvorrichtung 46 stammen können. Das Rollen der Daten von den festgeschriebenen Deltas 43 vorwärts zur Master-Vorrichtung 44 erscheint allgemein als ein "Lesen", gefolgt von einem "Schreiben" in die Master-Vorrichtung 44. Der Unterschied besteht darin, daß die Daten auch aus dem Puffer oder den Seiten- Cache-Speichern 41 kommen können. Die beeinflußten Deltas 43 werden aus der Logbuchabbildung 54 entfernt. Der Rollen/Lesen-Codeblock 56 ist mit den Master- und Logbuchvorrichtungen 44, 46 sowie mit den Schreib- und Lesepuffern 50, 52 und den Schnittstellen zum Puffer oder zu den Seiten-Treibern 58 verbunden.
In Fig. 4 ist gezeigt, daß früh im Startprozeß die On- line-Disksuite-("ODS")-Zustandsdatenbanken abgetastet werden und der In-Kern-Zustand für die Metavorrichtungen neu erzeugt wird. Jede Metavorrichtung wird dargestellt durch eine Einheitsstruktur, wobei die Einheitsstruktur für die Metatrans-Vorrichtungen die Adresse ihrer Logbuchführungsvorrichtungseinheitsstruktur enthält, und umgekehrt. Die Einheitsstruktur der Metatrans-Vorrichtung 60 ist mt_unit_t und ist in mt_trans.h definiert. Die Einheitsstruktur der Logbuchführungsvorrichtung 62 ist ml_unit_t und ist ebenfalls in mt_trans.h definiert.
Wie in Fig. 5 gezeigt, werden die Einheitsstrukturen der Logbuchführungsvorrichtung 62 in einer global verknüpften Liste gehalten, die mittels ul_list verankert ist. Jede der Einheitsstrukturen der Metatrans-Vorrichtung 60 für die Metatrans-Vorrichtungen 60, die eine Logbuchführungsvorrichtung 62 gemeinsam nutzen, werden in einer verknüpften Liste gehalten, die durch die Einheitsstruktur der Logbuchführungsvorrichtung verankert ist.
Wie außerdem in Fig. 6 gezeigt ist, wird, nachdem die Einheitsstrukturen eingerichtet worden sind, für jede Logbuchführungsvorrichtung 62 ein Abtastvorgang gestartet. Der Abtastvorgang ist ein Kernvorgang, der eine Logbuchvorrichtung 62 abtastet und die Logbuchabbildung 64 für diese Logbuchführungsvorrichtung 62 neu erstellt. Die Logbuchabbildung 64 ist mt_map_t und ist in mt_trans_h definiert. Die Logbuchabbildung 64 enthält einen mapentry t für jedes Delta 43 im Logbuch, das in die Master-Vorrichtung gerollt werden muß. Die Abbildungseinträge 68 werden von den Sammelankern 66 (Metatrans-Vorrichtung, Metatrans-Vorrichtungsoffset) für schnelle Nachschlagvorgänge während der Leseoperationen gesammelt. Um die Leistung zu steigern, werden die Abbildungseinträge 68 ferner in einer verknüpften Liste in der Reihenfolge gehalten, in der sie hineingerollt werden sollen. Wie in Fig. 7 schematisch gezeigt ist, enthalten die Einheitsstrukturen für die Metatrans-Vorrichtung 60 und die Logbuchführungsvorrichtung 62 die Adresse der Logbuchabbildung 64 (Logbuchabbildung 54 in Fig. 3), die den gesammelten Abbildungseinträgen 70 und allen Abbildungseinträgen 72 zugeordnet ist.
Wie ferner in Fig. 8 gezeigt, ist eine Deltaabbildung 74 jeder Metatrans-Vorrichtung 60 zugeordnet. Die Deltaabbildung 74 speichert Informationen über die Änderungen, die eine Dateisystemoperation umfaßt. Das Dateisystem informiert die Metatrans-Vorrichtung 60 über diese Änderungen (oder Deltas 43), in dem sie das Tupel (Offset an Master-Vorrichtung 44, Anzahl der Bytes an Daten und Rückruf) mit der Vorrichtung aufzeichnet. Die Metatrans- Vorrichtung 60 erzeugt in Verbindung mit den Sammelankern 76 einen Abbildungseintrag 78 für jedes Delta 43, das in der Deltaabbildung 74 gespeichert ist (Deltaabbildung 48 in Fig. 3). Die Deltaabbildung 74 ist mt_map_t ähnlich der Logbuchabbildung 64 (Fig. 6 und 7) und besitzt die gleiche Struktur.
Wie ferner in Fig. 9 gezeigt, wird am Ende einer Transaktion der mit jedem Abbildungseintrag 68 aufgezeichnete Rückruf im Fall von "Schreibvorgängen", die Logbuchdaten verwenden, aufgerufen. Der Rückruf ist eine Funktion im Dateisystem, die bewirkt, daß die dem Delta 43 zugeordneten Daten geschrieben werden. Wenn dieser "Schreibvorgang" im Metatrans-Treiber erscheint, erfaßt der Treiber eine Überlappung zwischen dem geschriebenen Puffer 80 und den Deltas 43 in der Deltaabbildung 74. Wenn keine Überlappung vorliegt, wird der Schreibvorgang zur Master- Vorrichtung 44 (Fig. 3) weitergeleitet. Wenn eine Überlappung erfaßt wird, werden die überlappenden Abbildungseinträge aus der Deltaabbildung 74 entfernt und zur Logbuchabbildungsschicht hinuntergereicht.
Die Logbuchabbildungsschicht speichert das Delta 43 zuzüglich der Daten im Schreibpuffer 50 des Logbuches und setzt die Abbildungseinträge in die Logbuchabbildung 64 ein. Es ist zu beachten, daß die Daten für ein Delta 43 vor dem Ende einer Transaktion geschrieben worden sein können, wobei dann der gleiche Prozeß verfolgt wird. Sobald die Daten in den Schreibpuffer 50 des Logbuchs kopiert sind, wird der Puffer E/A-behandelt.
Ein Grund für die Verwendung der Architektur mt_map_t für die Deltaabbildung 74 ist, daß der Treiber nicht kmem_alloc benutzen kann. Der Speicher für jeden Eintrag, der in der Logbuchabbildung erscheinen kann, muß zugewiesen werden, bevor der Puffer im Treiber erscheint. Da es eine 1-zu-1-Entsprechung zwischen den Deltas 43 in der Deltaabbildung 74 und den Einträgen in der Logbuchabbildung 64 gibt, ist es offensichtlich, daß die Deltaabbil dungseinträge 78 die gleichen sein sollten wie die Logbuchabbildungseinträge 68.
In Fig. 10 ist die analoge Situation von "Lesevorgängen" gezeigt, die Logbuchdaten verwenden. Wie gezeigt, wird die Logbuchabbildung 64 auch für Leseoperationen verwendet. Wenn der gelesene Puffer nicht mit irgendeinem der Einträge 68 in der Logbuchabbildung 64 überlappt, wird der "Lesevorgang" einfach zur Master-Vorrichtung 44 hinuntergereicht. Wenn andererseits der Puffer mit Einträgen 68 in der Logbuchabbildung 64 überlappt, sind die Daten für den Puffer eine Kombination aus Daten von der Master-Vorrichtung 44 und aus Daten von der Logbuchführungsvorrichtung 46.
In den Fig. 11 und 12 ist die Situation zum Einbindungs- Zeitpunkt schematisch gezeigt. Früh im Startprozeß zeichnet jede Metatrans-Vorrichtung sich selbst mit der USF- Funktion ufs_trans_set auf und erzeugt eine ufstrans- Struktur 84 und bindet diese in eine globale verknüpfte Liste ein. Zum Einbindungs-Zeitpunkt vergleicht das Dateisystem sein dev_t mit den dev_t, die in den ufstrans-Strukturen 86 gespeichert sind. Wenn eine Übereinstimmung vorliegt, speichert das Dateisystem die Adresse der ufstrans-Struktur 86 und ihre dateisystemspezifische per-mount-Struktur ufsvfs 90. Das Dateisystem speichert ferner seine generische per-mount-Struktur vfs 88 in der ufstrans-Struktur 86. Diese Aktivität wird bewerkstelligt von mountfs() und von ufs_trans_get(). Die Adresse von vfs 88 ist aufgrund der Tatsache, daß die Adresse von verschiedenen Rückruffunktionen benötigt wird, in der ufstrans-Struktur 86 gespeichert.
Das Dateisystem kommuniziert mit dem Metatrans-Treiber 32 (Fig. 2, 3) durch Aufrufen der Einsprungpunkte in der Struktur ufstransops 92. Diese Einsprungpunkte enthalten die begin-Operation, die end-Operation und die record- delta-funktion. Diese drei Funktionen führen gemeinsam einen Großteil der Arbeit durch, der für die Transaktionssoperationen der UFS-Schicht 30 erforderlich sind. Die Fig. 13 zeigt eine Zusammenfassung der Datenstrukturen der vorliegenden Erfindung, wie sie in den vorangehenden Figuren dargestellt sind und wie im folgenden genauer beschrieben wird.
Die Metatrans-Vorrichtung oder der Treiber 32 enthält zwei darunterliegende Vorrichtungen, eine Logbuchführungsvorrichtung 46 und eine Master-Vorrichtung 44. Diese beiden können Plattenvorrichtungen oder Metavorrichtungen (jedoch keine Metatrans-Vorrichtungen) sein. Beide stehen unter der Kontrolle des Metatrans-Treibers und sollten im allgemeinen für Benutzerprogramme oder andere Teile des Systems nicht direkt zugänglich sein. Die Logbuchführungsvorrichtung 46 enthält ein Journal oder Logbuch. Das Logbuch ist eine Sequenz von Aufzeichnungen, von denen jede einer Änderung am Dateisystem beschreibt (ein Delta 43). Der Satz von Deltas 43, der den momentan aktiven vnode-Operationen entspricht, bildet eine Transaktion. Wenn eine Transaktion abgeschlossen ist, wird im Logbuch eine Festschreibungsaufzeichnung plaziert. Wenn das System abstürzt, werden irgendwelche nicht festgeschriebenen Transaktionen, die im Logbuch enthalten sind, beim Neustart verworfen. Das Logbuch kann ferner Benutzerdaten enthalten, die synchron (z. B. mittels NFS) geschrieben worden sind. Das Aufzeichnen dieser Daten verbessert die Dateisystemleistung, ist jedoch nicht verbindlich. Wenn nicht ausreichend Logbuchraum verfügbar ist, können die Benutzerdaten direkt in die Master-Vorrichtung 44 geschrieben werden. Die Master-Vorrichtung 44 enthält ein UFS-Dateisystem im Standardformat. Wenn eine Vorrichtung, die bereits ein Dateisystem enthält, als Master-Vorrichtung 44 verwendet wird, werden die Dateisysteminhalte ge sichert, so daß die Aufrüstung vom Standard-UFS zur Erweiterung der vorliegenden Erfindung einfach ist. Der Metatrans-Treiber aktualisiert die Master-Vorrichtung 44 mit abgeschlossenen Transaktionen und Benutzerdaten. Metaclear(lm) löst die Metatrans-Vorrichtung 32 auf, so daß die Master-Vorrichtung 44 bei Bedarf erneut mit dem Standard-UFS verwendet werden kann.
Die Metatrans-Vorrichtung 32 stellt herkömmliche Roh- und Blockschnittstellen dar und verhält sich ähnlich einer gewöhnlichen Plattenvorrichtung. Eine separate Transaktionsschnittstelle erlaubt dem Dateisystemcode, dem Treiber Dateisystemaktualisierungen mitzuteilen. Die Inhalte der Vorrichtung umfassen die Inhalte der Master-Vorrichtung 44, die durch die im Logbuch aufgezeichneten Deltas 43 modifiziert sind.
Über die Transaktionsschnittstelle informiert das UFS den Treiber, welche Daten sich in der aktuellen Transaktion ändern (z. B. die inode-Modifikationszeit) und wann die Transaktion beendet ist. Der Treiber konstruiert Logbuchaufzeichnungen, die die aktualisierten Daten enthalten, und schreibt diese in das Logbuch. Wenn das Logbuch ausreichend voll wird, rollt der Treiber dieses vorwärts. Um den Logbuchraum wiederzuverwenden, müssen die im Logbuch aufgezeichneten abgeschlossenen Transaktionen an die Master-Vorrichtung 44 weitergeleitet werden. Wenn die von der Transaktion modifizierten Daten in einer Seite oder in einem Puffer im Speicher verfügbar sind, schreibt der Metatrans-Treiber diese einfach in die Master-Vorrichtung 44. Andernfalls müssen die Daten aus der Metatrans-Vorrichtung 32 gelesen werden. Der Treiber liest die ursprünglichen Daten von der Master-Vorrichtung 44, liest anschließend die Deltas 43 aus dem Logbuch und wendet diese an, bevor er die aktualisierten Daten in die Master-Vorrichtung 44 zurückschreibt. Die effektive Cache-Speicherung von SunOSTM, die von Sun Microsystems Inc. entwickelt und lizensiert ist, bewirkt, das der letztere Fall nur selten auftritt und in den meisten Fällen das Logbuch sequentiell geschrieben wird und letztlich nicht gelesen wird.
Das UFS kann ferner vorangehende Deltas 43 löschen, da eine nachfolgende Operation ihre Wirkung aufgehoben hat. Dieses Löschen ist notwendig, wenn ein Block von Metadaten, z. B. ein Zuweisungsblock, freigegeben und anschließend als Benutzerdaten neu zugewiesen wird. Ohne Löschung könnten Aktualisierungen der alten Metadaten irrtümlich auf die Benutzerdaten angewendet werden.
Der Metatrans-Treiber verfolgt die Inhalte des Logbuchs und verwaltet dessen Raum. Er hält die Datenstrukturen für die Transaktionen und Deltas 43 und hält eine Abbildung, die die Logbuchaufzeichnungen den Orten in der Master-Vorrichtung 44 zuweist. Wenn das System abstürzt, werden diese Strukturen aus dem Logbuch das nächste mal, wenn die Vorrichtung verwendet wird, rekonstruiert (wobei jedoch nicht festgeschriebene Transaktionen ignoriert werden). Das Logbuchformat stellt sicher, daß teilweise geschriebene Aufzeichnungen oder ungenutzer Logbuchraum nicht fehlerhaft für gültige Transaktionsinformationen gehalten werden. Ein Kernvorgang wird erzeugt, um das Logbuch abzutasten und die Abbildung beim ersten Lesen oder Schreiben in eine Metatrans-Vorrichtung 32 neu aufzubauen. Datenübertragungen werden zurückgestellt, bis der Kernvorgang abgeschlossen ist, obwohl Treiberoperationen, die keine Eingabe/Ausgabe erfordern, fortgesetzt werden können.
Einer der Hauptvorteile der vorliegenden Erfindung ist, die Metadaten gegen Korruption durch Stromausfall zu schützen. Dies bewirkt eine Einschränkung für die Inhalte des Logbuches in dem Fall, in dem der Metatrans-Treiber ein Delta 43 auf die Master-Vorrichtung 44 anwendet, wenn der Strom ausfällt. In diesem Fall kann das Dateisystemobjekt, das aktualisiert wird, teilweise geschrieben oder sogar korrumpiert werden. Die gesamten Inhalte des Objekts aus dem Logbuch müssen weiterhin wiederhergestellt werden. Um dies zu bewerkstelligen, garantiert der Treiber, daß eine Kopie des Objekts sich im Logbuch befindet, bevor das Objekt in die Master-Vorrichtung 44 geschrieben wird.
Die Metatrans-Vorrichtung 32 versucht nicht, irgendwelche anderen Typen von Medien-Ausfällen zu korrigieren. Zum Beispiel versetzt ein Vorrichtungsfehler während des Schreibens oder Lesens der Logbuchführungsvorrichtung 46 die Metatrans-Vorrichtung 32 in einen Ausnahmezustand. Der Zustand der Metatrans-Vorrichtung 32 wird in der MDD- Datenbank gehalten. Es gibt unterschiedliche Ausnahmezustände, die auf dem Typ des Fehlers beruhen und darauf, wann der Fehler auftritt.
Die Konfiguration der Metatrans-Vorrichtung 32 kann unter Verwendung von Standard-MDD-Hilfsmitteln durchgeführt werden. Das MDD-Dynamikverkettungsmerkmal erlaubt die dynamische Erweiterung sowohl der Master- als auch Logbuchführungsvorrichtungen 44, 46. Die Vorrichtungskonfiguration und andere Zustandsinformationen sind in der MDD-Zustandsdatenbank gespeichert, die über die Neustartvorgänge hinweg eine Wiederherstellung und eine Stetigkeit bieten. Der zum Speichern der Informationen erforderliche Raum ist relativ klein, in der Größenordnung eines Plattensektors pro Metatrans-Vorrichtung 32.
In einer bestimmten Implementierung der vorliegenden Erfindung prüft das UFS zum Einbindungs-Zeitpunkt, ob ein Dateisystem auf einer Metratrans-Vorrichtung 32 beruht, indem es ufs_trans_get() aufruft. Wenn das Dateisystem nicht auf einer Metatrans-Vorrichtung 32 beruht, gibt diese Funktion NULL zurück; andernfalls gibt sie einen Hantierer zurück, der die Metatrans-Vorrichtung 32 identifiziert. Dieser Hantierer wird in der mount-Struktur für die Verwendung bei nachfolgenden Transaktionsoperationen gespeichert. Die Funktionen TRANS_BEGIN() und TRANS_END() zeigen den Anfang und das Ende der Transaktionen. TRANS_DELTA() identifiziert eine Änderung des Dateisystems, die im Logbuch aufgezeichnet werden muß. TRANS_CANCEL() läßt das UFS anzeigen, daß vorher im Logbuch aufgezeichnete Deltas 43 gelöscht werden sollten, da eine Dateisystemdatenstruktur wiederverwendet oder verworfen wird.
Wenn das Dateisystemprüfhilfsmittel ("fsck") auf einem Dateisystem gemäß der vorliegenden Erfindung läuft, prüft es den Sauber-Merker des Dateisystems im Superblock und fragt die Dateisystemvorrichtung über einen Befehl ioctl ab. Wenn sowohl der Superblock als auch die Vorrichtung darin übereinstimmen, daß das Dateisystem auf einer Metatrans-Vorrichtung 32 beruht, und die Vorrichtung nicht irgendwelche Ausnahmebedingungen meldet, ist fsck fähig, eine weitere Prüfung auszulassen. Andernfalls prüft es das Dateisystem in herkömmlicher Weise.
Wenn das "quotacheck"-Hilfsmittel auf einem Dateisystem gemäß der vorliegenden Erfindung läuft, prüft es den Sauber-Merker des Systems im Superblock und fragt das Dateisystem über einen Befehl ioctl ab. Wenn sowohl der Superblock als auch die Vorrichtung darin übereinstimmen, daß das Dateisystem auf einer Metatrans-Vorrichtung 32 beruht, und die Vorrichtung nicht irgendwelche Ausnahmebedingungen meldet, muß quotacheck die quota-Datei nicht neu erstellen. Andernfalls erstellt es die quota-Datei für das Dateisystem in herkömmlicher Weise neu.
Der Logbuchführungsmechanismus der vorliegenden Erfindung stellt die Dateisystemkonsistenz sicher, mit Ausnahme des verlorenen freien Raums. Wenn geöffnete, jedoch gelöschte Dateien (d. h. nicht durch irgendeinen Verzeichniseintrag bezeichnete Dateien) vorhanden waren, als das System abgeschaltet wurde, gehen die Dateisystembetriebsmittel, die von diesen Dateien beansprucht werden, vorübergehend verloren. Ein Kernvorgang wird diese Betriebsmittel neu beanspruchen, ohne den Dienst zu unterbrechen. Als eine Leistungsoptimierung zeigt ein vorher unbenutztes Feld im Superblock des Dateisystems, fs_sparecon[53], ob irgendwelche Dateien dieser Art existieren. Bei Bedarf kann fsck den verlorenen Raum sofort neu beanspruchen, wobei fs_sparecon[53] in fs_reclaim umbenannt wird.
Verzeichnisse können durch eine lokale Anwendung oder durch einen Dämon, der auf Geheiß eines entfernten Clients in einem Client-Server-Computersystem läuft, verändert werden. In der Standard-UFS-Implementierung werden sowohl entfernte als auch lokale Verzeichnisänderungen synchron durchgeführt, d. h. Aktualisierungen eines Verzeichnisses werden auf die Platte geschrieben, bevor die Anfrage zur Anwendung oder zum Dämon zurückkehrt. Lokale Verzeichnisoperationen sind synchron, so daß das Dateisystem zum Neustartzeitpunkt automatisch repariert werden kann. Das NFS-Protokoll erfordert synchrone Verzeichnisoperationen. Unter Verwendung der Technik der vorliegenden Erfindung werden entfernte Verzeichnisänderungen synchron durchgeführt, jedoch werden lokale Verzeichnisänderungen im Speicher gehalten und nicht in das Logbuch geschrieben, bis ein sync(), fsync() oder eine synchrone Dateisystemoperation diese herauszwingt. Als Ergebnis können lokale Verzeichnisänderungen verloren gehen, wenn das System abstürzt, jedoch bleibt das Da teisystem konsistent. Lokale Verzeichnisänderungen bleiben geordnet.
Das Halten der lokalen Verzeichnisaktualisierungen im Speicher steigert die Leistung erheblich. Dies bewirkt eine Änderung in der Dateisystemsemantik, da abgeschlossene Verzeichnisoperationen nun nach einem Systemabsturz verschwinden. Das alte Verhalten ist jedoch durch keinen Standard vorgeschrieben, wobei erwartet wird, daß wenige Anwendungen, wenn überhaupt, durch die Änderung beeinflußt werden. Dieses Merkmal ist in herkömmlichen Dateisystemen, wie z. B. Veritas, Episode und das Logbuchstrukturierte Dateisystem vom Ousterhout und Mendelblum, implementiert. Die Benutzer können optional zu synchronen lokalen Verzeichnisaktualisierungen zurückkehren.
Das MDD-Initialisierungshilfsmittel metainit(lm) kann erweitert werden, um die Konfigurationszeilen der folgenden Form zu akzeptieren:
mdNN -t Master-Logbuch [-n].
mdNN Ein Metavorrichtungsname, der die Metatrans- Vorrichtung darstellt.
master Die Mastervorrichtung; eine Metavorrichtung oder eine gewöhnliche Plattenvorrichtung.
log Die Logbuchvorrichtung; eine Metavorrichtung oder eine gewöhnliche Plattenvorrichtung. Das gleiche Logbuch kann in mehreren Metatrans-Vorrichtungen verwendet werden, wobei es in diesem Fall von diesen gemeinsam genutzt wird.
Metastat kann ebenfalls erweitert werden, um den Status der Metatrans-Vorrichtungen mit dem folgenden Format anzuzeigen:
ndXX: Metatrans-Vorrichtung
Master-Vorrichtung: mdYY
Logbuchführungsvorrichtung: mdZZ
< Statusinformation>
mdYY: Metaspiegel, Mastervorrichtung für mdXX
< üblicher Status>
mdZZ: Metaspiegel, Logbuchführungsvorrichtung für mdXX
< üblicher Status>
Fsck entscheidet auf der Grundlage des Zustands des Sauber-Merkers, ob das System zu prüfen ist. Die spezielle Implementierung der vorliegenden Erfindung, die hier beschrieben wird, definiert einen neuen Sauber-Merker- Wert FSLOG. Wenn der Sauber-Merker gleich FSLOG ist und die Metatrans-Vorrichtung 32 sich nicht in einem Ausnahmezustand befindet, endet "fsck -m" mit 0 und die Prüfung wird ausgelassen. Andernfalls wird der Sauber-Merker in herkömmlicher Weise behandelt und fsck prüft den Zustand der Metatrans-Vorrichtung 32 mit einer Projekt-privat- ioctl-Anfrage. Nach einer erfolgreichen Reparatur eines Dateisystems gibt fsck eine Projekt-privat-ioctl-Anfrage aus, die die Metatrans-Vorrichtung 32 aus dem Ausnahmezustand nimmt.
Wenn der Sauber-Merker gleich FSLOG ist und die Metatrans-Vorrichtung 32 sich nicht in einem Ausnahmezustand befindet, läßt quotacheck das Dateisystem aus. Andernfalls erstellt quotacheck die quota-Datei in herkömmlicher Weise. quotacheck prüft den Zustand der Metatrans- Vorrichtung 32 mit einer Projekt-privat-ioctl-Anfrage.
Nach einer erfolgreichen Reparatur eines Dateisystems gibt quotacheck eine Projekt-privat-ioctl-Anfrage aus, die den Ausnahmezustand der Metatrans-Vorrichtung 32 zurücksetzt.
Das Programm ufs-mount kann zwei neue Optionen akzeptieren, um zu steuern, ob verzögerte Verzeichnisaktualisierungen verwendet werden sollen.

Vorspanndateien

< sys/fs/ufs_inode.h>
Die Struktur ufsvfs kann einen Zeiger auf die Struktur metatrans enthalten, um die Metatrans-Vorrichtung zu identifizieren. i_doff wird der Struktur inode hinzugefügt.
< sys/fs/ufs_quota.h>
Die Struktur dquot kann das neue Feld dg_doff besitzen.
< sys/fs/ufs_fs.h>
Der neue Sauber-Merkerwert FSLOG wird hier definiert.
fs_sparecon[53] wird umbenannt zu fs-reclaim.
< sys/fs/ufs_trans.h>
< sys/md_trans.h>
Diese sind neue Vorspanndateien, die Projekt-privat- Schnittstellen definieren, wie z. B. Metatrans-iocti- Befehle und Datenstrukturen.

Kernschnittstellen

common/fs/ufs/*.c
Die VOP- und VFS-Schnittstellen des UFS müssen nicht verändert werden, sofern nicht ein Merker zu den Verzeichnis-VOP-Aufrufen hinzugefügt wird, um einen lokalen und einen entfernten Zugriff zu unterscheiden. Aufrufe an die Metatrans-Logbuchführungsschnittstelle werden mehreren internen UFS-Funktionen hinzugefügt.
common/vm/page_lock.c
Die folgenden Funktionen erlauben einen bedingten Zugriff auf eine Seite: page_io_lock(), page_io_unlock(), page_io_trylock ut page_io_assert().
common/vm/vm_pvn.c
Die folgende Funktion erlaubt ein Lösen der Seiten, die unter Verwendung der vorangehenden Funktionen aufgenommen wurden: pvn_io_done.
common/os/bio.c
Eine neue Funktion trygetblk() wird bio.c hinzugefügt. Diese Funktion prüft, ob ein Puffer für die spezifizierte Vorrichtung und eine Blocknummer existieren und ob er für einen Schreibvorgang sofort zur Verfügung steht. Wenn diese Bedingungen erfüllt sind, gibt sie einen Zeiger auf den Puffervorspann zurück, oder gibt NULL zurück, wenn sie nicht erfüllt sind.

Vorgangsspezifische Daten (TSD)

TSD können zum Prüfen verwendet werden. Jedes Delta 43 in einer Dateisystemoperation wird dem Vorgang zugeordnet, der das Delta 43 hervorruft.
UFS-mount speichert den von ufs_trans_get() zurückgegebenen Wert im ufsvfs-Feld vfs_trans. Ein NULL-Wert bedeutet, daß das Dateisystem nicht von einer Metatrans-Vorrichtung 32 eingebunden ist. Die UFS-Funktionen sind in diesem Fall wie üblich beschaffen. Ein Nicht-NULL-Wert bedeutet, daß das Dateisystem von einer Metatrans-Vorrichtung eingebunden ist. In diesem Fall gilt:
a) Der On-Disc-Sauber-Merker ist auf FSLOG gesetzt und die weitere Sauber-Merkerverarbeitung ist durch Setzen des in-Kern-Sauber-Merkers auf FSBAD gesperrt. Das Sperren der Sauber-Merker-Verarbeitung spart CPU- Verwaltungsaufwand ein.
b) Der Merker DIO ist gesetzt, sofern nicht die mount- Option "nosyncdir" spezifiziert ist. Lokale Verzeichnisaktualisierungen werden mit einem verzögerten Schreibvorgang aufgezeichnet. Ein Absturz könnte diese Operationen verlieren. Fernverzeichnisoperationen bleiben synchron. Verzeichnisoperationen werden als fern betrachtet, wenn T_DONTPEND im curthread- > t_flag gesetzt ist.
c) Eine Ausnahmeroutine wird zum Einbindungs-Zeitpunkt mit der Metatrans-Vorrichtung 32 registriert. Die Metatrans-Vorrichtung ruft diese Routine auf, wenn eine Ausnahmebedingung eintritt. Ausnahmebedingungen umfassen Vorrichtungsfehler und detektierte Inkonsistenzen im Zustand des Treibers. Die UFS-Ausnahmeroutine startet einen Kernvorgang, der die beeinträchtigten Dateisysteme hart sperrt.
Jede UFS-Vnode- oder VSF-Operation kann eine oder mehrere Transaktionen erzeugen. Transaktionen können verschachtelt sein, so daß eine Transaktion Untertransaktionen enthalten kann, die vollständig in dieser enthalten sind. Verschachtelte Transaktionen treten auf, wenn eine Operation weitere Operationen auslöst. Typischerweise besitzt jede UFS-Operation eine Transaktion (plus irgendwelche verschachtelten Transaktionen), die ihr zugeordnet ist. Bestimmte Operationen jedoch, wie z. B. VOP_WRITE und VFS_SYNC, sind in mehrere Transaktionen unterteilt, wenn eine einzelne Transaktion die Gesamtgröße der Logbuchfüh rungsvorrichtung 46 überschreiten würde. Andere, wie z. B. VOP_CMP und VOP_ADDMAP, erzeugen keine Transaktionen, da sie niemals den Dateisystemzustand ändern. Einige Operationen, die das Dateisystem nicht direkt ändern, können Transaktionen als Folge von Nebeneffekten erzeugen. Zum Beispiel kann VOP_LOOKUP einen Eintrag im dnlc- oder inode-Cache ersetzen, was bewirkt, daß in-Kerninodes inaktiv werden und die zugeordneten Seiten auf die Platte geschrieben werden.
Transaktionen beginnen mit einem Aufruf an TRANS_BEGIN(). Die Transaktion endet, wenn TRANS_END aufgerufen wird. Eine Transaktion umfaßt Deltas 43, die Aktualisierungen der Metadaten des Dateisystems sind. Metadaten sind der Superblock, die Zusammenfassungsinformationen, Zylindergruppen, inodes, Zuweisungsblöcke und Verzeichnisse. Das UFS identifiziert die Deltas 43 für die Metatrans-Vorrichtung 32 durch Aufrufen von TRANS_DELTA(). Dieser Aufruf identifiziert einen Bereich von Bytes innerhalb eines Puffers, der im Logbuch aufgezeichnet werden sollte. Diese Bytes werden im Logbuch aufgezeichnet, wenn der Puffer geschrieben wird. Das UFS ändert häufig die gleichen Metadaten mehrmals für eine einzige Operation. Das Trennen der Deklaration des Deltas 43 von der Logbuchaufzeichnung des Deltas 43 führt mehrere Aktualisierungen zu einem Delta 43 zusammen.
Das UFS enthält Plattenblöcke für Benutzerdaten und Zuweisungsblöcke für den gleichen freien Pool. Als Ergebnis können die Benutzerdaten Stellen auf der Platte besetzen, die zu einem früheren Zeitpunkt Metadaten enthalten haben. Der Logbuchentwurf muß sicherstellen, daß während der Wiederherstellung die Benutzerdaten nicht fehlerhaft mit Deltas 43 für frühere Metadaten aktualisiert werden. Das UFS verhindert dies durch Aufrufen von TRANS_CANCEL() immer dann, wenn ein Block für Benutzerdaten zugewiesen wird.
Schreibvorgänge in die Roh- oder Block-Metatransvorrichtung 32 können im Logbuch aufgezeichnete Informationen ungültig machen. Um Inkonsistenzen zu vermeiden, überträgt der Treiber diese Schreibvorgänge.
Die Logbuchführungsvorrichtung 46 erhöht die synchrone Schreibleistung durch Zusammenführen synchroner Schreibvorgänge und durch Schreiben der gestapelten Daten sequentiell in die Logbuchführungsvorrichtung 46. Die Daten werden asynchron zum gleichen Zeitpunkt in die Master-Vorrichtung 44 geschrieben. Die im Logbuch aufgezeichneten synchronen Schreibdaten sind nicht in Transaktionen organisiert. Die Metatrans-Vorrichtung 32 zeichnet synchrone Schreibdaten transparent im Logbuch auf, ohne Eingriff auf Dateisystemebene. Synchron geschriebene Benutzerdaten werden nicht im Logbuch aufgezeichnet, wenn im Logbuch nicht ausreichend freier Raum vorhanden ist. In diesem Fall wird ein gewöhnlicher synchroner Schreibvorgang in die Master-Vorrichtung 44 durchgeführt.
Wenn synchrone Schreibdaten im Logbuch aufgezeichnet werden, müssen irgendwelche früheren Logbuchaufzeichnungen für die gleiche Plattenstelle gelöscht werden, um falsche Änderungen an den Daten während der Wiederherstellung oder des Vorwärtsrollens zu vermeiden. Wenn das asynchrone Schreiben der Daten in die Master-Vorrichtung 44 beendet ist, plaziert die done-Routine des Metatrans- Treibers eine Löschaufzeichnung in einer Liste von im Logbuch aufzuzeichnenden Elementen. Nachfolgende synchrone Schreibvorgänge in die gleiche Plattenstelle werden gefolgt von einer synchronen Festschreibung, die diese Aufzeichnung in das Logbuch setzt und den vorherigen Schreibvorgang löscht. Nachfolgende asynchrone Schreibvorgänge an die gleiche Stelle verschwinden beim Neustart, sofern ihnen nicht ein sync(), fsync() oder eine weitere synchrone Aktualisierung folgen. Die Richtigkeit dieses Schemas hängt von der Tatsache ab, daß das UFS keinen neuen Schreibvorgang in eine Plattenstelle startet, während eine vorangehende noch in Arbeit ist.
Die Master-Vorrichtung 44 wird periodisch mit den festgeschriebenen Änderungen im Logbuch aktualisiert. Änderungen, die am Kopf des Logbuches aufgezeichnet sind, werden zuerst gerollt. Drei Leistungsmaßnahmen reduzieren den Aufwand des Rollens des Logbuches. Erstens, der Treiber vermeidet das Lesen des Logbuchs, wenn die benötigten Daten entweder im Puffer-Cache oder im Seiten-Cache verfügbar sind. Zwei neue Routinen, trygetblk() und ufs_trypage(), geben einen Puffervorspann oder eine Seite zurück, ohne zu warten, oder geben NULL zurück. Zweitens, überlappende Deltas 43 werden gelöscht. Wenn das Logbuch mehrere Aktualisierungen für die gleichen Daten enthält, wird nur der benötigte minimale Satz aus dem Logbuch gelesen und angewendet. Die dritte Maßnahme verwendet die nicht übertragenen synchronen Schreibdaten. Diese Daten werden synchron in die Logbuchführungsvorrichtung 46 und asynchron in die Master-Vorrichtung 44 geschrieben. Die Roll-Logik wartet einfach, bis der asynchrone Schreibvorgang abgeschlossen ist.
Das Rollen wird vom Metatrans-Treiber eingeleitet. Wenn die Logbuchführungsvorrichtung 46 gefüllt wird, rollt der Metatrans-Treiber sofort das Logbuch in den Inhalt des aktuellen Vorgangs. Andernfalls ermittelt der Metatrans- Treiber heuristisch, wann das Rollen effizient ist, und startet einen Kernvorgang. Eine offensichtliche Heuristik für diesen Fall ist, wenn der Metatrans-Treiber für mehrere Sekunden im Leerlauf ist. Das Logbuch wird bei fsync(), sync() oder unmount nicht gerollt, wird jedoch gerollt, wenn die Metatrans-Vorrichtung durch das Hilfsmittel metaclear(lm) gelöscht wird.
Die Metatrans-Vorrichtung 32 versetzt sich selbst in einen Ausnahmezustand, wenn ein Fehler auftritt, der einen Datenverlust bewirken kann. In diesem Zustand gibt die Metatrans-Vorrichtung 32 bei jedem Lesen oder Schreiben nach dem Aufrufen aller registrierten "Rückruf-bei- Ausnahme"-Routinen für die Vorrichtung ein EIO zurück.
Das UFS registriert einen Rückruf auf die Routine beim Einbindungs-Zeitpunkt. Die UFS-Routine startet einen Kernvorgang, der die beeinträchtigten UFS-Dateisysteme hart verriegelt, was eine manuelle Wiederherstellung erlaubt. Die übliche Prozedur ist, das Dateisystem zu auskoppeln, den Fehler zu beheben, und fsck auszuführen. Fsck nimmt die Vorrichtung aus dem Ausnahmezustand, nachdem es das Dateisystem repariert hat. Das Dateisystem kann anschließend eingebunden werden, wobei das Dateisystem normal funktioniert. Wenn das Dateisystem ausgekoppelt ist und anschließend erneut eingebunden wird, ohne fsck laufenzulassen, gibt jeder Schreibvorgang für die Vorrichtung EIO zurück, jedoch werden Lesevorgänge fortgeführt, wenn auf die geforderten Daten zugegriffen werden kann.
Das UFS muß keinen Logbuchraum herausgeben, wobei dann, wenn der Metatrans-Treiber eine Transaktion aufgrund ungenügenden Logbuchraums nicht festschreiben kann, die Bedingung als schwerwiegende Ausnahme behandelt wird. Das UFS vermeidet diese Situation durch Aufteilen bestimmter Operationen in mehrere Transaktionen, falls erforderlich. Die UFS-Löschroutinen erzeugen eine Transaktion für jeden Aufruf ufs_syncip() oder VOP_PUTPage. Die Löschroutinen sind ufs_flushi(), ufs_iflush() und ufs_flush_icache(). Die beeinflußten UFS-Operationen sind VFS_Sync und VFS_UNMOUNT sowie die UFS-ioctls FIOLFS, FIOFFS und FIODIO. Eine VOP_WRITE-Operation wird in mehrere rwip()- Aufrufe im uss_write() unterteilt.
Das Freigeben einer Datei in ufs_iinactive() kann nicht in mehrere Transaktionen unterteilt werden, da Endlosschleifenprobleme mit Transaktionskollisionen und rekursiven UFS-Operationen auftreten und das Freigeben der Datei verzögert wird, bis keine Möglichkeit für eine Endlosschleife besteht.
Der Metatrans-Treiber stellt nicht die Betriebsmittel wieder her, die von geöffneten, gelöschten Dateien beim Neustart gehalten werden. Statt dessen behandelt das UFS dieses Problem. Ein Kernvorgang, der zum Einbindungs- Zeitpunkt erzeugt worden ist, sucht nach gelöschten Dateien, wenn:
a) das Dateisystem auf einer Metatrans-Vorrichtung 32 ist, oder
b) der Superblock mitteilt, daß gelöschte Dateien vorhanden sind. Ein Bit in einem vorher ungenutzten Freiraum im Superblock zeigt an, ob irgendwelche solche Dateien vorhanden sind.
Der Treiber der Metatrans-Vorrichtung 32 behandelt drei Klassen von Fehlern: "Vorrichtungsfehler", "Datenbankfehler" und "interne Fehler". Die Vorrichtungsfehler sind Fehler beim Lesen oder Schreiben der Logbuchführungs- oder Master-Vorrichtungen 46, 44. Datenbankfehler sind Fehler, die von Datenbankroutinen der MDDs gemeldet werden. Interne Fehler sind erfaßte Inkonsistenzen in internen Strukturen, einschließlich der Strukturen, die in die Logbuchführungsvorrichtung 46 geschrieben worden sind.
Eine eingebundene Metatrans-Vorrichtung 32 antwortet auf Fehler auf eine von zwei Arten. Der Metatrans-Treiber leitet Fehler, die die Datenintegrität nicht beeinträchtigen, ohne eine weitere Aktion an den Aufrufer weiter. Dieser Typ von Fehler kann z. B. auftreten, während nicht im Logbuch eingetragene Daten von der Master-Vorrichtung 44 gelesen werden. Die Metatrans-Vorrichtung 32 versetzt sich immer dann selbst in einen Ausnahmezustand, wenn ein Fehler zu einem Verlust von Daten oder zu korrumpierten Daten führen kann, wie z. B. ein Fehler beim Lesen oder Schreiben in die Logbuchführungsvorrichtung 46 oder bei einem Fehler der Datenbankroutinen des MDD. Eine Metatrans-Vorrichtung 32 versetzt sich selbst in einen Ausnahmezustand durch:
a) Aufzeichnen der Ausnahme in der Datenbank des MDD, falls möglich.
b) Aufrufen irgendwelcher registrierter "Rückruf-bei- Ausnahme"-Routinen. Diese Routinen werden mit der Vorrichtung beim Einbindungs-Zeitpunkt registriert. Das UFS registriert eine Routine, die einen Kernvorgang startet, der die beeinträchtigten UFS-Dateisysteme hart sperrt. Diese Dateisysteme können ausgekoppelt werden und anschließend, nachdem die Ausnahmebedingung korrigiert worden ist, erneut eingebunden werden.
c) Zurückgeben von EIO bei jedem Lese- oder Schreibaufruf, während die Metatrans-Vorrichtung 32 eingebunden ist.
Nachdem die Metatrans-Vorrichtung 32 durch das UFS beim Auskoppeln mit ufs_trans_put()gelöst worden ist, geben Lesevorgänge EIO zurück, wenn die angeforderten Daten nicht zugänglich sind, wobei Schreibvorgänge immer EIO zurückgeben. Dieses Verhalten besteht auch dann, nachdem die Metatrans-Vorrichtung 32 erneut eingebunden ist.
Wenn fsck das Dateisystem repariert, nimmt es die Metatrans-Vorrichtung 32 aus ihrem Ausnahmezustand. Fsck gibt zuerst ein Projekt-privat-ioctl aus, das das Logbuch bis zum ersten Fehler rollt, und verwirft den Rest des Logbuches und stellt die Vorrichtung für Schreibvorgänge zur Verfügung. Nach dem Reparieren des Dateisystems gibt fsck ein Projekt-privat-ioctl aus, das die Vorrichtung aus ihrem Ausnahmezustand nimmt.
Zum Neustartzeitpunkt wird die Logbuchführungsvorrichtung 46 abgetastet und der interne Zustand der Metatrans- Vorrichtung 32 wird neu erstellt. Ein Vorrichtungsfehler während des Abtastens versetzt die Metatrans-Vorrichtung 32 in den Ausnahmezustand. Die Abtastung wird fortgesetzt, falls möglich. Ein unlesbarer Sektor, der aus einem unterbrochenen Schreibvorgang resultiert, wird durch Neuschreiben desselben repariert. Die Metatrans- Vorrichtung 32 wird nicht in einen Ausnahmezustand versetzt.
Vorwärtsrolloperationen können auftreten, während die Logbuchführungsvorrichtung 46 abgetastet wird und der interne Zustand neu erstellt wird. Vorwärtsrolloperationen treten auf, wenn der Abbildungsspeicher seine benötigte Zuweisung überschreitet. Fehler während dieser Vorwärtsrolloperationen versetzen die Metatrans-Vorrichtung 32 in einen Ausnahmezustand, wobei die Abtastung fortgesetzt wird, falls möglich.
Es ist klar, daß die verzögerte Aufzeichnung lokaler Verzeichnisaktualisierungen die Leistung verbessern kann. Zwei Mechanismen zum Unterscheiden lokaler und entfernter (NFS) Verzeichnisoperationen können implementiert sein: a) das UFS kann das p_as-Element der proc-Struktur untersuchen (wenn es gleich 0 ist, ist der Aufrufer ein Systemprozeß, vorzugsweise NFS; andernfalls wurde die Operation von einem Benutzerebene-Prozeß eingeleitet und ist als lokal zu behandeln); oder b) das Hinzufügen eines neuen Merkers zu den Vnode-Operationen für Verzeichnisse, die spezifizieren, ob die Operation synchron sein muß (oder hinzufügen eines neuen Merkers zur Vorgangsstruktur).
Die Betriebsmittel, die geöffneten, jedoch gelöschten Dateien zugeordnet sind, müssen neu beansprucht werden, nachdem ein System abstürzt, wobei die vorliegende Erfindung zu diesem Zweck einen Kernvorgang enthält. Ein Vorgang, der immer das gesamte Dateisystem nach solchen Dateien durchsucht, besitzt jedoch zwei Nachteile: der Aufwand des Suchens und die möglicherweise beträchtliche Verzögerung, bis Raum gefunden und wiederhergestellt worden ist. Eine Alternative ist, ein freies Feld im Superblock zu verwenden, um diesen Fall zu optimieren, indem keine solchen Dateien vorhanden sind, was wahrscheinlich sehr häufig auftritt.
Der FIOSDIO-ioctl versetzt das UFS-Dateisystem in den verzögerten EA-Modus, was bedeutet, das lokale Verzeichnisaktualisierungen mit verzögerten Schreibvorgängen auf die Platte geschrieben werden. Entfernte Verzeichnisaktualisierungen bleiben synchron, da dies vom MFS-Protokoll gefordert wird. Dieser Modus macht Verzeichnisoperationen sehr schnell, ist jedoch ohne die vorliegende Erfindung unsicher, wobei ein Reparieren eines Dateisystems im DIO-Modus üblicherweise einen Benutzereingriff erfordert. Der Logbuchführungsmechanismus der vorliegenden Erfindung mildert die Gefahr. Um die Verzeichnisaktualisierungsleistung zu verbessern, können die Dateisy steme in den verzögerten EA-Modus versetzt werden, sofern nicht die "nosyncdir"-mount-Option spezifiziert ist. Die Implementierung des verzögerten EA-Modus ändert sich jedoch erheblich und eine Lösung ist, die Verwendung des FIOSDIO-Merkers zu vermeiden und statt dessen einen anderen speziellen Merker zu verwenden. Dieser spezielle Merker kann von einem neuen Hilfsmittel und einem Projekt-privat-UFS-ioctl verwaltet werden. Der neue Merker kann im Superblock gespeichert sein oder kann in der Datenbank des MDD gespeichert sein. Der FIOSDIO-ioctl würde dann keinen Einfluß auf ein Dateisystem gemäß der vorliegenden Erfindung haben.

UFS-Schnittstelle zur Metatrans-Vorrichtung

Eine Metatrans-Vorrichtung 32 zeichnet sich selbst mit dem UFS auf, wenn die Metatrans-Vorrichtung 32 erzeugt wird oder beim Neustart neu erzeugt wird:
dev ist die Metatrans-Vorrichtungsnummer. data ist die Adresse der Metatrans-privat-Struktur. ops ist die Adresse der Verzweigungstabelle:
ufs_trans_set speichert die obige Information in einer einfach verketteten Liste von:
ufs_trans-reset() entkettet die Struktur ufstrans und gibt sie frei. ufs_trans-reset() wird aufgerufen, wenn eine Metatrans-Vorrichtung gelöscht wird.
Zum Einbindungs-Zeitpunkt speichert OFS die Adresse einer ufstrans-Struktur im Feld vsf_trans einer Struktur ufsvfs:
Wenn ufs_trans-get NULL zurückgibt, wenn das Dateisystem nicht auf einer Metatrans-Vorrichtung 32 beruht, wird ufs_trans onerror von der Metatrans-Vorrichtung 32 aufgerufen, wenn ein schwerwiegender Vorrichtungsfehler auftritt. ufs_trans_onerror_state wird als Teil des Fehlerzustands der Metatrans-Vorrichtung 32 gespeichert. Dieser Fehlerzustand wird von fsck und quotacheck abgefragt und zurückgesetzt.
Das UFS ruft die Metatrans-Vorrichtung über die Tabelle ufstransops auf. Diese Aufrufe sind innerhalb der folgenden Makros verdeckt:
Neben dem Feld vfs_trans in der Struktur ufsvfs wird ein neues Feld of_ft i_doff der *incore*-inode-Struktur hinzugefügt. i_doff wird in ufs_iget() gesetzt. i_doff ist der Vorrichtungsoffset für dinode von inode. i_doff reduziert die Menge an Code für die Makros TRANS_INODE() und TRANS_INODE_ITEM(). In ähnlicher Weise wird das Feld dq_boff der Struktur "inocre"-quota und der Struktur dquot hinzugefügt.
Das Protokoll zwischen ufs_iinactive() und ufs_igit() wird verändert, da das System abstürzt, wenn eine Operation für fsA eine Transaktion für fsB bewirkt. Dies geschieht in ufs_iinactive, wenn es einen inode freigibt oder wenn es ufs_synchip() aufruft. Dies geschieht in ufs_iget () wenn es ufs_synchip () bei einem inode aus der freien Liste aufruft. In der Implementierung der vorliegenden Erfindung reinigt ein Vorgang im Leerlauf befindliche inodes und bewegt diese von ihrer Leerlaufwarteschlange zu einer neuen "Wirklich-frei"-Liste. Die inodes in der "Wirklich-frei"-Liste sind wirklich frei und enthalten keinen Zustand. Tatsächlich sind sie lediglich Abschnitte des Speichers, die die richtige Größe für einen inode besitzen. ufs_iget() verwendet inodes aus dieser Liste oder neue inodes von kmen_alloc().
Der Vorgang läuft, wenn die Anzahl der inodes in ihrer Warteschlange 25% des ufs_ninode überschreiten. ufs_ninode A ist die vom Benutzer vorgeschlagene maximale Anzahl von inodes im inode-Cache. Es ist zu beachten, daß ufs_ninode nicht die Größe des inode-Cache beschränkt. Die Anzahl der aktiven inodes und die Anzahl der im Leerlauf befindlichen inodes mit Seiten kann unbegrenzt bleiben. Der Vorgang reinigt inodes, bis deren Warteschlangenlänge weniger als 12,5% von ufs_ninode beträgt.
Einige neue Zähler können der inode-Zustandsstruktur hinzugefügt werden:
ufs_iinactive gibt die von gelöschten Dateien auf der Platte gehaltenen Betriebsmittel frei. Das Freigeben von inodes in ufs_iinactive kann das System zum Absturz bringen, wie oben beschrieben, wobei die gleiche Lösung verwendet werden kann, d. h. die gelöschten Dateien werden von einem Vorgang verarbeitet. Die Warteschlange des Vorgangs ist auf ufs_ninode-Einträge beschränkt. ufs_rmdir() und ufs_remove() verstärken die Einschränkung.
Das System stürzt ab, wenn ein Vorgang die Verriegelung des inode-Cache hält, wenn er fortgesetzt wird, während er in eine Transaktion eintritt. Ein Vorgang stellt das Eintreten in eine Transaktion zurück, wenn zu diesem Zeitpunkt nicht ausreichend Logbuchraum verfügbar ist. Die inode-Abtastfunktionen ufs_flushi, ufs_iflush und ufs_flush-inodes verwenden eine einzige Abtast-inode- Sammelfunktion, die nicht den inode-Cache-Riegel hält:
ufs_iget verwendet das gleiche Protokoll. Dieses Protokoll ist möglich, da das neue iget/iinactive-Protokoll die Probleme beseitigt, die bei dem Versuch der Neuverwendung eines im Cache gespeicherten inode inhärent sind.
Die lockfs-flush-Routine ufs_flush-inodes wird geändert, um die vorliegende Erfindung zu bilden. ufs_flush-inodes verdeckt inodes, während sie diese löscht. Die inodes werden verdeckt, indem sie aus dem inode-Cache entnommen werden, gelöscht werden und anschließend in den Cache zurückgesetzt werden. Verdeckte inodes können jedoch am Ende von Transaktionen nicht gefunden werden. ufs_ flushinodes verwendet nun die neue inode-Sammel-Abtastfunktion, um inodes zu löschen.
ufs_unmount() wird modifiziert, um das lockfs-Protokoll und die neue inode-Sammel-Abtastfunktion zu verwenden. ufs_unmount() verwaltet ferner die UFS-Vorgänge. Alle Vorgänge werden erzeugt, gesteuert und vernichtet von einem gemeinsamen Satz von Routinen in ufs_thread.c. Jeder Vorgang wird durch folgende Struktur dargestellt:
Mit zusätzlichem Zug auf die folgende Pseudocode-Auflistung kann der Transaktionsvorrichtungstreiber für ein von Schreiboperationen in eine Computermassenspeichervorrichtung im Fall des Systemausfalls genauer verstanden werden:

DATEISYSTEM-OPERATION:

Informiere Transaktionsvorrichtung, daß die Operation beginnt Führe übliche Dateisystemoperationen durch
.
.
.
Ändere wichtige Daten ---> Informiere Transaktionsvorrichtung
.
.
.
Ändere wichtige Daten ---> Informiere Transaktionsvorrichtung
.
.
.
Informiere Transaktionsvorrichtung, daß Operation geendet hat

TRANSAKTIONSVORRICHTUNG - BEGINNE OPERATION:

Weise Transaktions-ID zu Rücksprung

TRANSAKTIONSVORRICHTUNG - BEENDE OPERATION:

Festschreiben der Transaktion im Logbuch Rücksprung

TRANSAKTIONSVORRICHTUNG - WICHTIGE DATENMITTEILUNG:

Zeichne Plattenstelle der wichtigen Daten auf Rücksprung

TRANSAKTIONSVORRICHTUNG - NORMALER PLATTEN-SCHREIBVORGANG:

Wenn Daten wichtige Datenänderungen enthalten kopiere geänderte Daten in Logbuchpuffer Rücksprung
Sonst
Starte das Schreiben der Daten auf Platte Rücksprung

TRANSAKTIONSVORRICHTUNG - NORMALER PLATTEN-LESEVORGANG:

Lese Daten von Platte in Puffer
Wenn Logbuch Aktualisierung für diese Daten enthält Lese Aktualisierungen aus Logbuch Wende Aktualisierungen auf Puffer an Rücksprung
Obwohl oben die Prinzipien der vorliegenden Erfindung in Verbindung mit speziellen Computerbetriebssystemen beschrieben worden sind, ist die vorangehende Beschreibung lediglich beispielhaft angegeben und nicht als Beschränkung des Umfangs der Erfindung, die von den folgenden Ansprüchen definiert wird.

Claims

1. Verfahren zum Sicherstellen der Atomizität von bei einer Transaktion in eine Computermassenspeichervorrichtung geschriebenen oder aus dieser Vorrichtung ausgelesenen modifizierten Daten in Verbindung mit einem Computerbetriebssystem mit einem Journaldatei-System, enthaltend:

Angeben eines Beginns einer Dateisystem-(30)- Operation für eine ein Journalprotokoll (46) enthaltende Transaktionsvorrichtung und

Herstellen einer kerninternen Kopie von Dateisystem-(30)-Daten,

dadurch gekennzeichnet, daß die Transaktionsvorrichtung (32) eine Protokollvorrichtung (46) und eine Master-Vorrichtung (44) enthält, und durch die folgenden Schritte:

Ausführen der Dateisystem-Operation durch Verändern der kerninternen Kopie der Dateisystem-Daten;

Informieren der Transaktionsvorrichtung (32) über ausgewählte Eigenschaften der geänderten Daten;

Erklären eines Endes der Dateisystem-Operation für die Transaktionsvorrichtung (32);

Festschreiben der der Dateisystem-Operation entsprechenden geänderten Daten im Protokoll in der Protokollvorrichtung (46); und

Schreiben der geänderten Daten aus dem Protokoll in die Master-Vorrichtung (44).

2. Verfahren nach Anspruch 1, bei dem der Angabeschritt durch Zuweisen einer Identifizierungsnummer an die Dateisystem-Operation und durch Informieren der Transaktionsvorrichtung (32) über die Identifizierungsnummer ausgeführt wird.

3. Verfahren nach Anspruch 1, bei dem der Ausführungsschritt die Ausführung mehrerer Änderungen an der kerninternen Kopie der Dateisystem-Daten umfaßt.

4. Verfahren nach Anspruch 1, bei dem der Informierungsschritt durch Bestimmen eines Versatzes und der Größe der geänderten Daten ausgeführt wird.

5. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten:

Analysieren der geänderten Daten, um deren relative Wichtigkeit für das Dateisystem zu bestimmen; und

direktes Schreiben der geänderten Daten in die Master-Vorrichtung (44), falls die geänderten Daten für das Dateisystem nicht relativ wichtig sind.

6. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten:

Anfordern von Lesedaten von der Transaktionsvorrichtung;

Lesen von Daten von der Master-Vorrichtung (44) als Antwort auf die Anforderung unter Verwendung der Transaktionsvorrichtung;

Schreiben der Lesedaten in einen dem Protokoll entsprechenden Puffer (50);

Bestimmen, ob das Protokoll Aktualisierungen für die Lesedaten enthält;

Aktualisieren der Lesedaten im Puffer, falls das Protokoll Aktualisierungen für die Lesedaten enthält; und

Liefern der aktualisierten Lesedaten vom Puffer, um dem Anforderungsschritt zu genügen.

7. Computersystem zum Sicherstellen der Atomizität von bei einer Transaktion in eine Computermassenspeichervorrichtung geschriebenen oder aus dieser Vorrichtung ausgelesenen modifizierten Daten in Verbindung mit einem Computerbetriebssystem mit einem Journaldatei-System, mit

einer Einrichtung zum Angeben eines Beginns einer Dateisystem-(30)-Operation für eine ein Journal-Protokoll (46) enthaltende Transaktionsvorrichtung und

einer Einrichtung zum Erstellen einer kerninternen Kopie der Dateisystem-(30)-Daten,

dadurch gekennzeichnet, daß die Transaktionsvorrichtung (32) eine Protokollvorrichtung (46) und eine Master-Vorrichtung (44) enthält, und durch

eine Einrichtung zum Ausführen der Dateisystem- Operation durch Ändern der kerninternen Kopie der Dateisystem-Daten;

eine Einrichtung zum Informieren der Transaktionsvorrichtung (32) über ausgewählte Eigenschaften der geänderten Daten;

eine Einrichtung zum Erklären eines Endes der Dateisystem-Operation für die Transaktionsvorrichtung (32);

eine Einrichtung zum Festschreiben der der Dateisystem-Operation entsprechenden geänderten Daten im Protokoll in der Protokollvorrichtung (46); und

eine Einrichtung zum Schreiben der geänderten Daten aus dem Protokoll in die Master-Vorrichtung (44).

8. Computersystem nach Anspruch 7, ferner mit

einer Einrichtung zum Anfordern von Lesedaten von der Transaktionsvorrichtung;

einer Einrichtung zum Lesen von Daten von der Master-Vorrichtung (44) als Antwort auf die Anforderung unter Verwendung der Transaktionsvorrichtung;

einer Einrichtung zum Schreiben der Lesedaten in einen dem Protokoll entsprechenden Puffer (50);

einer Einrichtung zum Bestimmen, ob das Protokoll Aktualisierungen für die Lesedaten enthält;

einer Einrichtung zum Aktualisieren der Lesedaten im Puffer, falls das Protokoll Aktualisierungen für die Lesedaten enthält; und

einer Einrichtung zum Liefern der aktualisierten Lesedaten vom Puffer, um der Anforderungseinrichtung zu genügen.

9. Computersystem nach Anspruch 8, ferner mit

einer Delta-Abbildung (Delta-Map) (48) oder einer Abbildung der aktualisierten Lesedaten, die der Protokollvorrichtung (46) und dem dem Protokoll entsprechenden Puffer (50) zugeordnet ist.