-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft die Speicherung von Daten bei Stromausfällen. Insbesondere
betrifft die vorliegende Erfindung die Speicherung von Daten bei
Stromausfällen,
wobei eine zweite Stromquelle und eine private Liste verwendet werden,
um sicherzustellen, dass Daten nicht fehlerhaft überschrieben werden, wenn die
Stromversorgung zurückkehrt.
-
Hintergrund der Erfindung
-
Ein
wichtiger Maßstab
bei der Funktionsfähigkeit
eines Datei- bzw. Files-Servers ist die Zeit, die benötigt wird,
eine Anforderung eines Clients (Client Request) zu verarbeiten.
Ein anspruchsvoller Server wird auf Client Requests innerhalb kürzester
Zeit antworten. Im Falle von Schreiboperationen bei dem Datei- bzw. File-System,
ist es dem Server nicht erlaubt, die Anforderung zu bestätigen, bis
er garantieren kann, dass alle Nutzdaten es letzten Endes bis zum
Platten-Array schaffen. Falls die Daten in einem wichtigen Speicher
innerhalb des Servers gespeichert werden, würde ein Stromausfall den vollständigen Verlust
der Schreibdaten verursachen und seine Garantie für Daten-Integrität verletzen.
Ein Anschluss des Servers an eine unterbrechungsfreie Stromversorgung
für eine
sinnvolle Zeitdauer könnte
bezüglich
Kosten- und Platzbedarf unerschwinglich sein.
-
Die
vorliegende Erfindung stellt sicher, dass übergebene Nutzdaten von allen
Clients es letztendlich zur Festplatte schaffen, selbst dann, wenn
die Stromversorgung für
das System für
eine ausgedehnte Zeitdauer unterbrochen wird. Es bedarf keiner systemmäßigen Batterie-Vorrichtung.
Stattdessen wird nur eine kleine Reihe von batteriegepufferten Speichern
für eine
beständige
Speicherung in dem System verwendet.
-
Die
US-A-5 586 291 offenbart
ein Festplattenspeicher-Untersystem, das sowohl flüchtige wie
auch nicht-flüchtige
Speicherbereiche enthält.
Die von einem Host bereitgestellten Schreibdaten können in
zugewiesenen nicht-flüchtigen
Speicherblöcken
gespeichert werden und können
auch in zusätzlichen
nicht-flüchtigen Speichern
gespiegelt werden. Im Falle eines Stromausfalles werden Daten, die
in dem nicht-flüchtigen
Speicher gespeichert sind, aber noch nicht auf die Festplatte geschrieben
worden sind, konserviert. Jedes nicht-flüchtige Speichermodul kann eine
Batterie-Sicherungs-Stromquelle enthalten, die die nicht-flüchtigen Speichermodule
im Falle eines System-Stromausfalls versorgt.
-
Die
WO 92/15933 A offenbart
eine Datenspeicher-Einrichtung, die eine Speichereinrichtung umfasst, die
ein Stromsicherungs-System enthält.
Das Stromsicherungs-System ist eingerichtet, die Stromversorgung für die Speichereinrichtung
aufrechtzuerhalten, sollte die normale Stromversorgung unterbrochen
werden. Falls eine solche Stromversorgungs-Unterbrechung auftritt,
ist ein Speichermanager eingerichtet, alle aktualisierten Daten,
die in einem festen Statusspeicher auf einer Magnetfestplatte vor
dem Abschalten der Speichereinrichtung gespeichert sind, zu plazieren.
-
Die
US-A-5 761 406 offenbart
ein Verfahren zur Übertragung
von Daten von einem Speicher zu einem anderen innerhalb einer Speicher-Hierarchie
in einem Datenverarbeitungs-System. Falls die Stromversorgung abgeschaltet
wird und dann der Strom wieder eingeschaltet wird, werden hoch-priorisierte
Symbol-Bilddaten, die von einem RAM-Cache-Speicher zu einem Platten-Cache-Speicher übertragen
worden sind und in dem Platten-Cache-Speicher gesichert worden sind,
wenn das Ausdrucken nicht ausgeführt
worden ist, in dem RAM-Cache-Speicher wiederhergestellt.
-
Zusammenfassung der Erfindung
-
Gemäß eines
Aspektes der Erfindung wird eine Vorrichtung zur Übermittlung
von Daten eines Clients von einem Netzwerk gemäß Anspruch 1 und ein Verfahren
zur Übermittlung
von Daten eines Clients von einem Netzwerk gemäß Anspruch 10 bereitgestellt.
-
Kurze Beschreibung der Zeichnungen
-
In
den beiliegenden Zeichnungen werden das bevorzugte Ausführungsbeispiel
der Erfindung und bevorzugte Verfahren der Durchführung der
Erfindung veranschaulicht, wobei:
-
1 ein
Blockdiagramm von funktionalen Einheiten des File-Systems darstellt.
-
2 einer
schematischen Darstellung von NVRAM-Schreibdaten-Pufferstrukturen
entspricht.
-
3 einer
schematischen Darstellung einer NVRAM-Pufferung-Primär/Sekundär-Bereichs-Visualisierung
entspricht.
-
4 einer
schematischen Darstellung eines File-Systems der vorliegenden Erfindung
entspricht.
-
5 einer
schematischen Darstellung eines bevorzugten Ausführungsbeispiels eines File-Systems der
vorliegenden Erfindung entspricht.
-
Detaillierte Beschreibung
-
Bezug
genommen wird nun auf die Zeichnungen, in denen ähnliche Bezugszeichen sich
auf ähnliche oder
identische Teile überall
in den verschiedenen Ansichten und insbesondere in den 1 und 4 davon beziehen,
wobei dort ein File-Server 10 zum Bearbeiten von Daten
eines Clients eines Netzwerks 12 gezeigt wird. Der Server 10 umfasst
Plattenmittel 14 zum Speichern der Daten. Der Server 10 umfasst
Mittel zum Empfangen der Daten von dem Netzwerk 12 und
zum Senden einer Bestätigung,
dass die Daten gespeichert worden sind, an den Client über das
Netzwerk 12, jedoch bevor die Daten in den Plattenmitteln 14,
den Empfangsmitteln 16 in Kommunikation mit den Plattenmitteln 14,
gespeichert worden sind. Der Server 10 umfasst einen Speicher 18 zum
Speichern der Daten, bis die Daten in den Plattenmitteln 14 gespeichert
worden sind, wobei die Empfangsmittel 16 in Kommunikation
mit dem Speicher 18 stehen. Der Server 10 umfasst
eine erste Stromquelle 20, um Elektrizität für die Plattenmittel 14,
den Speicher 18 und die Empfangsmittel 16 bereitzustellen,
wobei die erste Stromquelle 20 in elektrischer Verbindung
mit den Plattenmitteln 14, dem Speicher 18 und
den Empfangsmitteln 16 steht. Der Server 10 umfasst
eine zweite Stromquelle 22, die Elektrizität für den Speicher 18 bereitstellt,
wenn die erste Stromquelle 20 ausfällt, wobei die zweite Stromquelle 22 in
Verbindung mit dem Speicher 18 steht.
-
Vorzugsweise
empfangen die Empfangsmittel 16 Daten in beliebiger Reihenfolge
von dem Client und schützen
die Daten davor, fälschlicherweise
in dem Speicher überschrieben
zu werden, wenn die Daten ungeordnet empfangen worden sind und die
erste Stromquelle 20 ausgefallen ist, bevor die Daten in
dem Speicher 18 gespeichert worden sind. Die Plattenmittel 14 enthalten
vorzugsweise ein Platten-Array 24 bzw. eine Anordnung von
Festplatten. Vorzugsweise enthält
der Speicher 18 NVRAM 26. Die Empfangsmittel 16 enthalten vorzugsweise
einen Anforderungs-Manager 28 bzw. Request-Manager, der
die Schreibdaten von anderen Informationen, die von einem Client
empfangen werden, trennt und diese Daten zu dem NVRAM 26 sendet.
-
Vorzugsweise
weist der Anforderungs-Manager 28 eine private Liste auf,
welche die Daten in einer Reihenfolge identifiziert, in der eine
Schreibanforderung eines Clients durch die Empfangsmittel 16 abgeschlossen
wird. Die private Liste wird von den Anforderungs-Manager 28 verwendet,
um sicherzustellen, dass die Daten in der Reihenfolge in dem Speicher 18 wiederhergestellt
werden, selbst dann, wenn die Anforderungen außerhalb der Reihenfolge verarbeitet
worden sind und die erste Stromquelle 20 ausgefallen ist,
bevor die Daten in das Platten-Array 24 geschrieben worden
sind. Die Empfangsmittel 16 enthalten vorzugsweise einen Inode-Manager 30,
der Anforderungen von Clients verarbeitet. Vorzugsweise enthalten
die Emfpangsmittel 16 einen Platten-Manager 32,
der das Platten-Array 24 managt
bzw. verwaltet und die Daten in oder aus dem Platten-Array 24 schreibt
oder liest. Die Empfangsmittel 16 enthalten vorzugsweise
einen Cache-Controller 34, der zumindest die Datenbereiche
managt bzw. verwaltet, welche in dem Speicher 18 gespeichert,
aber nicht in dem Platten-Array 24 gesichert worden sind.
-
Vorzugsweise
hält das
NVRAM 26 einen Rest bzw. einen Endteil eines Log-Files,
der in dem Platten-Array 24 angeordnet ist und alle Änderungen
von File-System-Metadaten verfolgt bzw. überwacht, um eine ordentliche
Datenwiederherstellung bzw. Datenrekonstruktion sicherzustellen,
wenn es zu einem Ausfall der ersten Stromquelle 20 kommt.
Das NVRAM 26 umfaßt
vorzugsweise NVRAM-Puffer 36, NVRAM-Deskriptoren 38 und ein Wiederherstellungs-Register 40.
Vorzugsweise speichern die NVRAM-Puffer 36 die Daten, so
wie sie von einem Client empfangen worden sind; die NVRAM-Deskriptoren 38 Aufnahme-Informationen,
die für die
Wiederherstellung der Daten in ihren zugewiesenen NVRAM-Puffern 36 wesentlich
sind; die freie Liste von NVRAM-Puffer 36; und das Wiederherstellungs-Register 40 hält einen
Kopf und einen Zähler
(head and count) der freien Liste. Die zweite Stromquelle 22 enthält vorzugsweise
eine Batterie bzw. Akku.
-
Vorzugsweise
weist der Anforderungs-Manager 28 eine Anforderungsnummer
der File-System-Anforderung
zu, die von den Empfangsmitteln 16 von dem Client des Netzwerks 12 empfangen
worden ist; wobei die Anforderungsnummer die Anforderung identifiziert.
Die Empfangsmittel enthalten vorzugsweise einen Anforderungsnummer-Statusspeicher,
und weitere Informationen enthalten vorzugsweise Call-Parameter
und Dateinamen, und der Anforderungs-Manager 28 sendet
die Call-Parameter und die Dateinamen zu dem Anforderungsnummer-Statusspeicher 42 und
sendet eine Nachricht an den Inode-Manager 30, dass die Anforderung
für die
Verarbeitung bereit ist. Vorzugsweise arbeiten der Anforderungs-Manager 28 und
der Inode-Manager 30 unabhängig voneinander, so dass der
Anforderungs-Manager 28 mit dem Empfang von Anforderungen
von Clients fortschreiten kann, während der Inode-Manager 30 Anforderungen
verarbeitet.
-
Der
Inode-Manager 30 beginnt vorzugsweise mit der Verarbeitung
der Anforderung durch Lesen der Call-Parameter der Anforderung aus
dem Anforderungsnummern-Statusspeicher 42,
um zu bestimmen, welcher Bearbeitungs- bzw. Operations-Typ von der
Anforderung angefordert wird. Vorzugsweise enthalten die Empfangsmittel
Cache-RAM, und der
Cache-Controller 34 empfängt Look-Up-Nachrichten von
dem Inode-Manager 30 und
dem Platten-Manager 32, was den Cache-Controller 34 veranlasst,
die Cache-Status-Tabellen zu suchen, die in dem Cache-RAM 44 für die angeforderten
Datenblöcke
angeordnet sind, die aktuellen Daten abzurufen, die mit dem Datenblock
des Plattenarrays 24 verknüpft sind, und den Cache-Zeiger
bzw. Cache-Pointer an die Cache-Status-Tabellen
zurückzugeben,
die kenntlich machen, wo die Schreibdaten plaziert worden sind;
und Nachrichten aufzufangen, die einen Cache-Zeiger enthalten und
Instruktionen bzw. Befehle für
das, was mit dem Status des verknüpften Cache-Blocks zu tun ist.
Wenn der Inode-Manager 30 eine Nachricht an den Anforderungs-Manager 28 sendet,
um die Schreibdaten von den NVRAM-Puffern 36 in bestimmte Datenblöcke in dem
Cache-RAM 44 zu schreiben, sendet der Inode-Manager 30 vorzugsweise
eine Änderungsnachricht
an den Cache-Controller 34, dass der Datenblock geändert worden
ist und in das Platten-Array 24 geschrieben werden muss.
-
Vorzugsweise übermittelt
der Platten-Manager 32 Schreibdaten von einem Cache-Zeiger
bzw. -Pointer an einen Plattenblock nachdem eine Auffangnachricht
(,fetch-message')
an den Cache-Controller 34 ausgegeben worden ist, der den
zugewiesenen Cache-Zeiger sperrt und temporär Änderungen verhindert. Der Cache-Controller 34 speichert
vorzugsweise eine NVRAM 26-Freigabeliste, die NVRAM-Puffer 36 miteinander verknüpft, welche
freigegeben werden müssen,
wenn ein Cache-Block gelöscht
wird. Das geschieht vorzugsweise, indem der NVRAM-Deskriptor 38 einen
ersten Bereich und einen zweiten Bereich der Daten in seinen NVRAM-Puffer 36 überwacht
bzw. verfolgt, welche in verschiedenen Cache-Blöcke gespeichert sind.
-
Die
vorliegende Erfindung betrifft ein Verfahren zum Verarbeiten von
Daten eines Clients von einem Netzwerk 12. Das Verfahren
umfasst die Schritte des Empfangens von Daten von dem Netzwerk 12 an
einen File-Server 10, der von einer Stromquelle 20 versorgt
wird. Es gibt den Schritt des Sendens einer Bestätigung an den Client über das
Netzwerk 12, dass die Daten in einem Platten-Array 24 des
Servers 10 gespeichert worden sind, jedoch bevor die Daten
in den Platten-Array 24 gespeichert worden sind. Es gibt
den Schritt des Speicherns der Daten in einem Speicher 18,
der von einer zweiten Stromquelle 22 versorgt wird, wenn
die erste Stromquelle 20 ausfällt, so dass die Daten nicht
verloren gehen, falls die erste Stromquelle 20 ausfällt, bis die
Daten in dem Platten-Array 24 gespeichert worden sind.
Es gibt den Schritt des Speicherns der Daten in dem Platten-Array 24.
-
Vorzugsweise
enthält
der Empfangsschritt den Schritt des Empfangens der Daten außerhalb
einer Reihenfolge; und der Speicherschritt enthält den Schritt eines Bewahrens
der Daten davor, dass sie fälschlicherweise
in dem Speicher 18 überschrieben
werden, wenn die Daten außerhalb
der Reihenfolge empfangen worden sind und die erste Stromquelle 20 ausgefallen
ist, bevor die Daten in dem Speicher 18 gespeichert worden
sind. Der Empfangsschritt enthält
vorzugsweise den Schritt der Pflege einer privaten Liste durch einen
Anforderungs-Manager 28 des Servers 10, welche
die Daten in der Reihenfolge kennzeichnet, in der eine Schreibanforderung
durch den Server 10 abgeschlossen wird und durch den Anforderungs-Manager 28 verwendet
wird, um sicherzustellen, dass die Daten in der Reihenfolge in dem
Speicher 18 wiederhergestellt werden, selbst dann, wenn
die Anforderungen außerhalb
der Reihenfolge verarbeitet worden sind und die erste Stromquelle 20 ausgefallen
ist, bevor die Daten in das Platten-Array 24 geschrieben worden
sind.
-
Vorzugsweise
enthält
der Speicherungsschritt für
die Daten in dem Speicher 18 den Schritt eines Speicherns
von Schreibdaten in dem NVRAM 28. Der Empfangsschritt enthält vorzugsweise
den Schritt des Trennens der Schreibdaten von anderen Informationen,
die von dem Client über
das Netzwerk 12 empfangen worden sind.
-
Vorzugsweise
enthält
der Empfangsschritt die Schritte einer Zuweisung einer Anforderungsnummer an
eine Anforderung, die mit den Daten verknüpft ist, und des Abbauens einer
Warteschlange durch genügend NVRAM-Puffer 36,
um die Schreibdaten zu bewahren.
-
Es
gibt vorzugsweise den Schritt des Abbauens einer Warteschlange durch
einen Anforderungs-Manager 28 des Servers 10 bezüglich eines
NVRAM 26-Zeigers vom Kopf bzw. Anfang einer freien Liste;
des Lesens eines Deskriptors des NVRAMS 26, um den Status
den NVRAM-Puffers 36 zu prüfen, den der Deskriptor repräsentiert.
Vorzugsweise gibt es die Schritte einer Null-Eliminierung durch
den Anforderungs-Manager 28 von
Statusbits des Deskriptors so lange, wie sich weder ein primärer Cache-Block noch ein sekundärer Cache-Block
des Cache-RAM 44 des Servers 10, der mit dem NVRAM 26 verknüpft ist,
in einem geschützten Status
befindet; des Kopierens durch den Anforderungs-Manager 28 eines
nächsten
Zeigerfeldes des Deskriptors in ein Wiederherstellungs-Register 40,
und des Zurückhaltens
des nächsten
Zeigerfeldes in dem Deskriptor im Falle, dass die erste Stromquelle 20 unterbrochen
wird, bevor das Wiederherstellungs-Register 40 aktualisiert
worden ist. Der Speicherschritt der Schreibdaten enthält vorzugsweise
die Schritte eines Schreibens der Schreibdaten in den NVRAM-Puffern 36 und
des Speicherns von Pufferzeigern in die entsprechenden NVRAM-Puffer 36 in
einen Anforderungsnummer-Statusspeicher 42.
-
Vorzugsweise
gibt es die Schritte der Benachrichtigung eines Inode-Managers 30 des
Servers 10 durch den Anforderungs-Manager 28,
dass die Anforderungsnummer der Anforderung zugewiesen worden ist; des
Schützens
der NVRAM-Puffer 36, die die Schreibdaten der Anforderung
halten; und des Verhinderns des Inode-Managers 30, die
Bestätigung
an den Client für
die Anforderung des Clients auszugeben. Der Schritt des Schützens enthält vorzugsweise
den Schritt des Sperrens mit dem Inode-Manager 30 in Zeigerfeldern
des Anforderungsnummern-Statusspeichers 42, um zu bestimmen,
welche NVRAM-Puffer 36 verwendet werden, um die Schreibdaten
für die
Anforderung zu halten; des Erzeugens einer physikalischen Adresse
für jedes
Zeigerfeld für
den NVRAM-Deskriptor 38;
des Schreibens mit dem Inode-Manager 30 des Deskriptors
in die NVRAM-Puffer 36; und des Setzens der primären und
sekundären
Cache-Blöcke
auf ,geschützt'. Vorzugsweise gibt
es den Schritt der Freigabe eines jeden unreinen Cache-Blocks mit einer
Blockfreigabe-Unrein-Nachricht (block release dirty message) von
dem Inode-Manager 30 an den Cache-Controller 34,
der identifiziert, welche NVRAM-Puffer 36 freigegeben werden
müssen,
wenn jeder unreine Cache-Block freigegeben wird.
-
Es
gibt vorzugsweise den Schritt der Freigabe durch den Anforderungs-Manager 28 eines
jeden NVRAM-Zeigers, der mit einem Cache-Block verknüpft ist,
nachdem er gelöscht
worden ist und der Anforderungs-Manager 28 eine Blocklöschungs-Antwortnachricht
von dem Platten-Manager 32 über den Cache-Controller 34 empfangen
hat.
-
Vorzugsweise
enthält
der Schritt der Freigabe die Schritte des Übermittelns der NVRAM 26-Zeigerliste von
dem Cache-Controller 34 an den Anforderungs-Manager 28;
des Änderns
mittels des Anforderungs-Managers 28 des Status der primären und
sekundären
Bereiche, wie durch den Cache-Controller 34 angezeigt, eines
jeden NVRAM 26-Zeigers in der Zeigerliste, auf den Freigabestatus,
sobald der Anforderungs-Manager 28 die NVRAM 26-Zeiger
empfängt,
während
der Anforderungs-Manager 28 die NVRAM 26-Zeiger zusammen in
einer privaten Liste verknüpft;
des Bestimmens mittels des Anforderungs-Managers 28, ob
der primäre
oder sekundäre
Bereich eines NSRAM 26-Zeigers
auf der privaten Liste, der nicht durch den Cache-Controller 34 angezeigt
wird, sich in dem geschützten
Status befindet; des Einordnens des NVRAM 26-Zeigers in
eine Warteschleife, so wie er von dem Anforderungs-Manager 28 empfangen
wird, zu dem Kopf bzw. Anfang der privaten Liste, falls der primäre oder
sekundäre
Bereich sich in dem geschützten
Status befindet oder zum Ende der privaten Liste, falls weder der
primäre
noch der sekundäre
Bereich geschützt
sind; des Anfügens
der privaten Liste zum Kopf bzw. Anfang der aktuellen freien Liste;
des Aktualisierens des Wiederherstellungs-Registers 40,
um auf den neuen Anfang der freien Liste zu zeigen und um alle Deskriptoren
aus der Warteschlange der freien Liste zu nehmen, welche sich nicht
in dem geschützten
Status befinden.
-
In
der Ausführung
der Erfindung stellt der File-Server ein verteiltes System von allgemein
verwendeten Prozessoren und benutzerspezifischen ASICs dar, die
durch die von ihnen ausgeführte
Funktion separiert sind. Integral mit dem Management dieser funktionalen
Einheiten ist ein Nachrichtensystem, das in der Lage ist, 32-Byte-Nachrichten
an und von jeder Einheit in dem Server in eine Warteschlange zu
stellen. Die vier funktionalen Einheiten, die mit dem Management
von File-Systemdaten und deren Übertragung
bzw. Übermittlung zu
dem Plattenuntersystem befasst sind, sind der Anforderungs-Manager,
der Inode-Manager, der Disk-Manager und Cache-Controller. Jede dieser
Einheiten ist in der Lage, Nachrichten an jede zu senden, wenn sie File-System-Anforderungen
verarbeiten. Die 1 zeigt, wie diese Einheiten
sich an jede andere und die sie unterstützenden Speicher anpassen.
Die dicken und durchgezogenen Linien zeigen den Datenfluss von den Clients
zu dem Platten-Array. Die dünnen
gestrichelten Linien zeigen Kommunikationskanäle zur Steuerung des Datenflusses.
-
Wenn
eine File-System-Anforderung von einem mit dem Netzwerk verbundenen
Client ankommt, wird sie unverzüglich
durch den Anforderungs-Manager bearbeitet. Bei Empfang einer neuen
Anforderung, wird der Anforderungs-Manager eine Anforderungsnummer
(RNUM) zuweisen, die verwendet wird, um sie durch die Verarbeitung
hindurch zu kennzeichnen. Der RQM (Request Manager) analysiert jede
File-System-Anforderung für
sich, um ihre Call-Parameter, Dateinamen und Schreibdaten zu separieren.
Während
Parameter und Dateinamen an den RNUM-Statusspeicher gesendet werden, werden
alle Schreibdaten, die in dem Call vorhanden sind, getrennt und
an die nicht-flüchtigen
RAM gesendet, um sie gegen Stromausfall zu schützen. Sobald die Analyse abgeschlossen
ist, wird der Anforderungs-Manager eine Nachricht an den Inode-Manager senden,
die ihn informiert, dass eine neue Client-Anforderung bereit ist, verarbeitet
zu werden. Weil der Anforderung-Manager und der Inode-Manager durch
ein Nachrichten-Warteschleifen-System getrennt sind, sind sie frei.
ihre Funktionen auszuführen,
ohne auf Antworten des anderen warten zu missen. Mit anderen Worten,
ist der Anforderungs-Manager frei, ein Bündel von Client-Anforderungen zu
verarbeiten, selbst dann, wenn der Inode-Manager an einer schwierigen
und langsamen File-System-Operation hängen bleibt. Der Anforderungs-Manager
wird nur durch die maximale Anzahl von RNUMs, die in dem System
programmiert sind, begrenzt.
-
Der
Inode-Manager ist der zentrale Prozessor der File-System-Befehle
und wird Nachrichten an verschiedene Einheiten verteilen, damit
deren Verarbeitung abgeschlossen wird. Der Inode-Manager wird darüber, dass
eine Anforderung wartet, durch den Empfang einer Nachricht des Anforderungs-Managers
informiert. Er beginnt dann mit der Verarbeitung durch Lesen der
Parameter des Calls von dem RNUM-Statusspeicher, um zu bestimmen,
welcher Typ von Bearbeitung bzw. Operation angefordert worden ist.
Dieser Prozessor ist programmiert, um alle Arten von File-System-Anforderungen,
die von einem Client erhalten werden können, zu verarbeiten. Während der
Verarbeitung wird der Inode-Manager Nachrichten an den Cache-Controller
senden, die anfordern, dass Inodes und Datenblöcke von dem Platten-Array abgerufen
werden. Er wird dann die Zeiger bzw. Pointer, die er von dem Cache-Controller
empfängt,
verwenden, um Daten an und von den Cache-RAM, wie zur Erledigung
der Client-Requests bzw. -Anforderung benötigt, zu übertragen. Falls er die Inhalte
eines Cache-Blocks ändert,
wird der Inode-Manager eine Nachricht an den Cache-Controller senden,
die diese Einheit informiert, dass ein Datenblock aktualisiert worden
ist und zu der Platte zurückgeschrieben
werden muss.
-
Der
Cache-Controller verwaltet Bereiche des File-Systems, welche in
den Speichern abgelegt sind, die sich näher an dem Client befinden
und viel geringere Latenzzeiten als die Platten-Arrays aufweisen.
Er empfängt
die grundlegenden Arten von Nachrichten von dem Inode-Manager und
dem Platten-Manager während
sie File-System-Anforderungen verarbeiten. Der erste Typ ist eine
Look-Up-Nachricht und veranlasst den Cache-Controller, die Cache-Status-Tabellen
nach den angeforderten Datenblöcken
zu durchsuchen, die Daten von der Platte, falls notwendig, abzurufen
und den Cache-Zeiger dorthin zurückzuweisen,
wo die Daten plaziert wurden. Der zweite Typ ist eine Abruf-Nachricht, die einen
Cache-Zeiger enthält
und Befehle über
das, was mit dem Cache- Zeiger-Status
zu tun ist. Weil verschiedene funktionelle Einheiten an den Cache-Eingängen arbeiten,
nehmen sie auf diese (durch Cache-Nachrichten) Bezug, um sicherzustellen,
dass sie nicht unerwartet replaziert bzw. ersetzt werden.
-
Der
Platten-Manager behandelt Nachrichten von dem Cache-Controller immer
dann, wenn Plattenaktivitäten
angefordert werden. Wenn eine Look-Up-Nachricht einen Cache-Verlust verursacht
hat, wird der Cache-Controller eine Lesenachricht an den Platten-Manager mit einem
Cache-Zeiger senden, wohin die Daten in dem Cache-RAM plaziert werden
sollen. Wenn ein Cache-Eingang geändert worden ist, wird der
Cache-Controller eine Schreibnachricht an den Platten-Manager mit
einem Cache-Zeiger senden, wohin die aktuellsten Daten angeordnet
sind, so dass sie zurück
zur Platte geschrieben werden können.
Damit der Platten-Manager Daten von einem Cache-Zeiger an einen
Plattenblock übermitteln
kann, muss er zuerst eine Abrufnachricht an den Cache-Controller
ausgeben, die um eine Sperrung auf dem Zeiger anfragt. Der Platten-Manager
wird nur dann Daten von dem Cache-Zeiger auf das Platten-Array kopieren,
wenn die Sperrung bewilligt worden ist. Dies stellt sicher, dass
die Inhalte des Datenblocks stabil sind, bevor die Übertragung
bzw. Übermittlung
beginnt. Der Platten-Manager sendet Befehle an den Cache-Controller,
um Daten von dem Cache-RAM zu verschieben. Er begründet seine
Entscheidungen auf die Ergebnisse von Algorithmen, die beschaffen
sind, die Effizienz der potenziell hochlatenten Festplatten bzw.
Platten zu optimieren. Außer
der Nachverfolgung von verunreinigten Seiten (dirty pages), haben
seine Entscheidungen darüber,
warm Daten aus dem Cache-Rahmen verschoben werden, wenig mit den
sich auf der Client-Seite des Systems auftretenden Ereignissen zu
tun.
-
Während der
Anforderungs-Manager die Anforderungen von dem Netzwerk akzeptiert,
weist er ihnen eine Kontext-ID zu, die während der Lebensdauer der Anforderung
in dem Server verwendet wird. Diese ID wird als ein RNUM bezeichnet.
Der RNUM-Status-Speicher
wird verwendet, um Informationen, die sich während der Verarbeitung der
Anforderung angesammelt haben, zu halten. Sie ist flüchtig und
wird als ungültg nach
einer Stromunterbrechung angesehen. Die Zeiger auf die NVRAM-Puffer,
die verwendet werden, um eingehende Client-Daten für die RNUM
zu halten, werden in diesem Bereich gespeichert.
-
Der
File-Server verwendet Cache-RAM, um einen Bereich des File-Systems
in einem gering latenten Speicher nahe der Clients zu pflegen. Während dieser
Speicher viel schneller als das Platten-Array ist, verbraucht er
eine Menge an Energie und ist deshalb als flüchtiger Speicher ausgeführt, der
alle Inhalte während eines
Stromausfalles verliert. Der Cache-Controller behandelt bzw. kontrolliert
den Cache-RAM durch Verwendung eines Rückschreib-Algorithmus (,write-back
algorithm') für eine verbesserte
Wirksamkeit.
-
Durch
Verschieben von Rückschreibe-Operationen
(,write-backs')
auf die Platte, kann der File-Server Daten von ähnlichen physikalischen Orten
in einer größeren Schreibanforderung
gruppieren, wobei die Funktionsfähigkeit
verbessert wird. Weil er das Zurückschreiben
von Daten zu den Platten verschiebt, wird der Cache-RAM eine aktualisiertere
Version des File-Systems als das Platten-Array selbst haben. Deshalb
müssen deren
Inhalte durch die NVRAM geschützt
bleiben, bis das Zurückschreiben
aufgetreten ist.
-
Ein
anderes Element, das in dem Cache-RAM gespeichert ist, ist die NVRAM-Freigabeliste. Dieser Speicher
wird von dem Cache-Controller verwendet, um NVRAM-Puffer, die bei Löschung eines
Cache-Blocks freigegeben werden müssen, miteinander zu verknüpfen. Ein
Maximum von 64k-Einträgen
werden für
diese Funktion unterstützt.
-
Jeder
Eintrag beträgt
8 Byte und ist wie folgt formatiert: Tabelle 1: NVRAM Freigabe Eintrag (8 Byte)
| 4 Bytes | Flags:
[31-2]:
Reserviert.
[1]: Frei, wenn der primäre Bereich freigegeben werden
soll.
Für
sekundären
Bereich gesetzt.
[0]: Gesetzt, wenn der letzte Eintrag in der
Freigabe Liste |
| 2 Bytes | NVRAM
Puffer-Zeiger:
Der gegenwärtige
NVRAM Puffer-Zeiger, der mit diesem NVRAM verknüpft ist |
| 2
Bytes | Nächster Eintrag
in Freigabe-Liste:
Falls dieser Eintrag nicht der letzte auf
der Liste ist, enthält
dieses Feld einen Zeiger auf den nächsten Eintrag auf der Freigabe-Liste. |
-
Wenn
der Cache-Controller eine Benachrichtigung des ersten NVRAM-Zeigers
erhält;
der eine Freigabeliste benötigt,
wird der Cache-Controller einen Eintrag dafür mit seinem Flag (0) setzen,
um anzugeben, dass er der letzte auf der Liste ist. Jeder nachfolgende
Zeiger, der auf der Liste plaziert werden muss, wird zum Anfang
der Liste hin eingereiht, wobei er auf den vorhergehenden Anfang
zeigt.
-
Der
nicht-flüchtige
RAM (NVRAM) in diesem System kann implementiert werden, indem jede Schwachstrom-Speichertechnologie
verwendet wird, die in der Lage ist, die Schreibdaten-Bandbreite
von dem Client zu tragen. Sein Stromversorgungs-System muss von
dem Rest des Systems getrennt werden, somit kann eine Umschaltung
auf Batteriesicherung bei Stromunterbrechen auftreten. Das NVRAM
hat zwei separate Zwecke. Erstens hält es das Ende des Lob Files,
welches alle Änderungen
an Datensystem-Metadaten verfolgt. Während Metadaten geändert werden,
wird eine Transaktion von alten und neuen Daten in dem Log-File
festgehalten, um eine sichere Wiederherstellung für den Fall
eines Server-Ausfalls sicherzustellen. Während das meiste der Datei
in der Platten-Array festgehalten wird, werden die aktuellsten Transaktionen
in dem NVRAM festgehalten, weil sie an das Ende des Log-Files angehängt werden.
Sobald genügend
Transaktionen sich aufsummiert haben, wird das Ende zur Platte in
einem großen
effizienten Bündel
verschoben. Indem man das Ende des Log-Files in einem schnellen
Speicher hält,
ist das File-System in der Lage, es höchst effizient zu halten.
-
Der
zweite Zweck des NVRAM dient zur temporären Speicherung von Schreibdaten
von Clients bevor das System sie in das Platten-Array schreibt.
Um diese Aufgabe zu erfüllen,
werden drei separate Strukturen in dem NVRAM aufrechterhalten. Diese
sind die 4 kB NVRAM-Puffer, die 32-Byte NVRAM-Deskriptoren und das
4-Byte Wiederherstellungs-Register. Die NVRAM-Puffer werden durch
den Server verwendet, um die Schreibdaten exakt, so wie sie von
dem Client ankommen, zu speichern. Die Puffergröße von 4 kB wurde gewählt; weil
sie zur Größe eines
Festplattenblockes und Cache-RAM-Puffers passt. Jedoch umfasst eine
andere potenzielle Größenoption,
dass der Puffer gleich der größten möglichen Übertragung
von Nutzdaten von dem Clienten gleichgesetzt wird. Noch eine weitere
Vorgehensweise wäre
es, sowohl kleine wie auch große Größen anzubieten,
um die Effektivität
des Speichers zu erhöhen,
falls viele kleine Schreibvorgänge
ankommen. Jeder Puffer hat einen einzelnen Deskriptor, der ihm zugewiesen
ist, um alle Details der Schreibdaten, die in dem NVRAM-Puffer gehalten
werden, anzugeben, so dass er nach einem Stromausfall wiederhergestellt bzw.
rekonstruiert werden können.
Die Deskriptoren werden auch verwendet, um eine freie Liste von
Puffer zu pflegen, von denen der Anforderungs-Manager beziehen kann,
während
er Client-Anforderungen verarbeitet. Während Plattenblöcke mit
Schreibdaten aus Cache-Blöcken
aktualisiert werden, werden die NVRAM-Puffer zu dem Ende der freien
Liste zurückgeführt. Das
Wiederherstellungs-Register wird verwendet, um den Kopf bzw. Anfang
sowie den Fehlerstand der freien Liste zu halten. Die 2 zeigt,
wie der File-Server die verwendeten NVRAM-Puffer überwacht
bzw. verfolgt, um Schreibdaten von seinen Clients zu halten.
-
Während der
Server gestaltet ist, bis zu 64 k NVRAM-Puffer zu unterstützen, wird
ein 16-Bit-Zeiger verwendet,
um jeden Puffer und seinen Deskriptor zu identifizieren und zu referenzieren.
Es wird angenommen, dass das Wiederherstellungs-Register lediglich
einen 16-Bit-Zeiger zu dem Deskriptor enthält, der sich an dem Kopf der
NVRAM-freien Liste befindet, und dass der 16-Bit-Zähler die
Anzahl der Deskriptoren sich auf dieser freien Liste befindet. Die
Inhalte des NVRAM-Deskriptors sind sehr wichtig für die Operation
bzw. den Betrieb der hier vorgeschlagenen beständigen Speicherarchitektur.
Dieses Feld wird bei Empfang von Schreibdaten initialisiert und
während
der Wiederherstellungs-Prozedur
geprüft.
Die Inhalte des NVRAM-Deskriptors sind in Tabelle 2 gezeigt. Tabelle 2: NVRAM Deskriptor (32 Byte)
| 12 Bytes | FID:
Die
Datei ID zu der die Daten in dem Puffer gehören. |
| 8 Bytes | Offset:
Der
Anfangs-Byte-Offset der Daten in der Datei. |
| 8 Bytes | Sequenz-Nummer:
Falls
der Puffer Daten enthält,
die wiederhergestellt werden müssen,
enthält
dieses Feld die Sequenz-Nummer, die der Anforderung zugeordnet ist, wenn
sie eintrifft. Diese wird verwendet, um eintreffende Schreib(-Operationen)
einzuordnen, um Fehlerfreiheit während
der Wiederherstellung sicherzustellen. |
| 4 Bytes | Status
Flags (4 Bits)
[3-2]: Primäre
Cache-Block-Status-Bits:
[1-0]: Sekundäre Cache-Block-Status-Bits.
'00': Ungültig. Ungültige Inhalte.
'01': Undefiniert.
'10': Freigebend. Stellt
Inhalte wieder her, falls Deskriptor nicht auf Freier Liste ist.
'11': Geschützt. Stellt
Inhalte unter allen Bedingungen wieder her. |
| Daten-Länge (12
Bits)
Die Menge an gültigen
Daten in dem NVRAM Puffer |
| Nächster Zeiger
(2 Bytes):
Falls der NVRAM Puffer auf der Freien Liste ist,
enthält
dieses Feld einen Zeiger auf den nächsten NVRAM Puffer auf der
Liste. Ein Wert von Nullen gibt das Ende der Liste an. |
-
Wie
in dem Deskriptor angezeigt, hat jeder NVRAM-Puffer einen primären und
einen sekundären
Bereich, die sich in einem unterschiedlichen Schutz-Zustand befinden
können.
-
Zur
Erläuterung
dieses Konzeptes soll folgendes Beispiel betrachtet werden. Falls
eine Client-Anforderung an den Server eintrifft, die 8 kB Schreibdaten
trägt,
müssen
zwei 4 kB NVRAM-Puffer für
den Empfang dieser Daten vorbereitet werden. Falls diese Daten einen
Anfangs-Offset von 1 kB in ihrer Datei aufweisen, werden die ganzen
8 kB-Daten letztendlich geschrieben, um 1 kB durch 9 kB anzurechnen.
Während
alle Cache-Blöcke
bei einer 4 kB Grenze beginnen, werden diese Daten drei getrennte
Cache-Blöcke
belegen, bevor sie zurück
in das Platten-Array geschrieben werden. Wie in 3 gezeigt,
werden die Schreibdaten in die NVRAM-Puffer 1 und 2 geschrieben.
Während
der Verarbeitung werden die Cache-Zeiger 100, 200 und 300 gewonnen
und verwendet, um die Schreibdaten zu empfangen. Wegen der 4 kB-Grenzen
bei den Cache-Blöcken,
sind die NVRAM-Puffer virtuell in zwei getrennte Bereiche, den primären und
den sekundären,
aufgeteilt worden. Der Cache-Block 100 hält Daten aus dem primären Bereich
des NVRAM-Puffers 1, während
der Cache-Block 200 Daten aus dem sekundären Bereich des NVRAM-Puffers
1 und des primären
Bereiches des NVRAM-Puffers
2 usw. hält.
In dem Fall, dass der Cache-Block 300 vor den anderen gelöscht wird,
wird das System wissen, das bloß der
sekundäre
Bereich des NVRAM-Puffers 2 noch freigegeben werden kann, wobei dieser
Puffer aus der freien Liste gehalten wird und noch Schutz für den primären Bereich
aufrecht erhalten wird.
-
Die
drei Phasen der Operation bzgl. der Aufrechterhaltung der NVRAM-Strukturen
während
der Dauer einer Schreib-Anforderung von einem Client wird nun beschrieben.
Jede Phase, die unten umrissen wird, weist zwei Unterbereiche bzw.
Unterabschnitte auf. Der erste Unterabschnitt beschreibt die Schritte,
die der Server durchgehen wird, während er diese Phase ausführt. Der
zweite Unterabschnitt stellt eine Analyse des Einflusses eines Stromausfalles
bereit, der während
der Phase auftreten kann. Diese Ausfallanalyse wird benötigt, um
sicherzustellen, dass Strom zu jeder Zeit ausfallen kann ohne die
Intaktheit der NVRAM-Strukturen zu beeinträchtigen.
-
Phase 1: Nutzdaten-Eingang
-
Beschreibung des Nutzdaten-Eingangs
-
Wenn
der File-Server eine Schreibanforderung von einem Client empfängt, wird
sie einer bestimmten Anforderungsnummer (RNUM) zugewiesen und wird
analysiert und durch den Anforderungs-Manager verteilt. Bevor er
dem mode-Manager mitteilt, dass die Anforderung eingetroffen ist,
muss er zuerst genügend
4 kB NVRAM-Puffer aus der Warteschlange bzw. Reihung nehmen, um
die gesamten Schreibdateninhalte zu halten. Weil die maximale Größe einer
Schreibanforderung 8 kB beträgt,
werden nicht mehr als zwei Puffer pro Anforderung benötigt.
-
Wenn
der Anforderungs-Manager einen NVRAM-Pointer bzw. -Zeiger aus der
Warteschlange von dem Anfang der freien Liste nimmt, wird er zunächst seinen
Deskriptor lesen, um den Status des Puffers, den er repräsentiert,
zu prüfen.
Solange, wie weder die primären
noch die sekundären
Cache-Blöcke
sich in den geschützten
Status befinden, wird der Anforderungs-Manager die Status-Bits in
den Deskriptor ausnullen. Er wird dann das nächste Zeigerfeld des neuerlich
aus der Warteschlange genommenen Deskriptors in das NVFREE_HEAD-Wiederherstellungs-Register
kopieren, weil es den neuen Kopf bzw. Anfang der freien Liste darstellt.
Das nächste
Zeigerfeld wird in dem aus der Warteschlange entnommenen Deskriptor
zurückgehalten im
Falle, dass der Strom unterbricht, bevor das NVFREE_HEAD-Register
aktualisiert worden ist. Falls der neuerlich aus der Warteschlange
entnommene Deskriptor vollständig
ausgenullt wurde, würde
die freie Liste einen Moment bzw. Zustand der Ungültigkeit
aufweisen, bis das NVFREE_HEAD-Wiederherstellungs-Register aktualisiert
worden ist. Das Setzen des NVRAM-Puffers in den Ungültigkeitszustand,
wird sicherstellen, dass es nicht wiederhergestellt wird, da es
sich nun außerhalb
der freien Liste befindet.
-
Falls
der Anforderungs-Manager feststellt, dass die Status-Flags des primären und
sekundären
Cache-Blöcke
auf ,geschützt' gesetzt sind, wird
er wissen, dass der Zeiger nicht vollständig freigegeben ist, und wird
ihn von der Liste allesamt entfernen. Während er den Deskriptor von
der freien Liste entfernt, ändert
er jeden Bereich im Freigabezustand auf ,ungültig', um die Wiederherstellung zu verhindern.
Folglich wird das nächste
Zeigerfeld des Deskriptors zu der NVFREE_HEAD-Wiederhersetellung
wie oben erwähnt,
kopiert.
-
Der
Anforderungs-Manager wird dann die Nutzdaten in die neulich angeforderten
Puffer schreiben und Zeiger auf den bzw. die Puffer an einem vorbestimmten
Ort in dem RNUM-Status-Speicher
speichern. Weil der Client noch keine Bestätigung empfangen hat, dass
die Daten übergeben
worden sind, sind diese Puffer noch nicht geschützt. Falls keine freien NRAM-Puffer
verfügbar
sind, wird die Client-Schnittstelle des Anforderungs-Managers verharren,
bis genügend
frei werden.
-
Ausfallanalyse des Nutzdaten-Eingangs
-
Die
einzige Modifikation an den NVRAM-Strukturen während des Nutzdaten-Eingangs
ist das Aus-der-Warteschlange-Nehmen von NVRAM-Puffern aus dem Kopf
der freien Liste. Während
dieses Vorgangs werden nur zwei Strukturen in einer sehr speziellen
Reihenfolge aktualisiert. Zuerst werden die Status-Flags des Deskriptors
von ,freigebend' auf
,ungültig' geändert, wobei
alle geschützten
Bereiche unverändert
bleiben. Weil keine anderen Felder des Deskriptors während dieser
Operation geändert
werden, wird ein Stromverlust während
seiner Aktualisierung bzw. Updates keinen Einfluss auf seinen Status
haben. Ein Eintrag auf der freien Liste, die ,ungültig' oder ,freigebend' ist, wird niemals
durch Definition wiederhergestellt. Falls der Strom ausfällt, nachdem
der Deskriptor aktualisiert worden ist, jedoch bevor das NVFREE_HEAD-Wiederherstellungs-Register
aktualisiert worden ist, wird die Wiederherstellungs-Prozedur bloß den jüngst von
der Warteliste genommenen Deskriptor noch am Anfang der freien Liste
finden und ihn nicht wiederherstellen. Da sein nächstes Zeigerfeld unverändert geblieben
ist, wird die Integrität
der freien Liste noch gewahrt.
-
Phase 2: Nutzdaten-Übergabe
-
Beschreibung der Nutzdaten-Übergabe
-
Sobald
der Anforderungs-Manager den mode-Manager benachrichtigt, dass eine
neue RNUM der Schreibanforderung zugewiesen worden ist, wird der
mode-Manager durch seine Prozedur für diesen Call gehen, bis es
Zeit ist, eine Antwort zurück
an den Client zu senden. Bevor diese Antwort gesendet wird, muss der
Inode-Manager sicher sein; die Speicherinhalte zu schützen. Um
diese Aufgabe zu erfüllen,
muss er zuerst in die Zeigerfelder des RNUM-Status-Speichers schauen,
um herauszufinden, welcher bzw. welche Puffer verwendet werden,
um die Schreibdaten für
diese Anforderung zu halten. Nur ein Zeiger ist gültig, falls
die Schreibanforderung 4 kB oder weniger betrug. Beide Zeiger sind
gültig
für Anforderungen
die größer als
4 kB sind. Der mode-Manager muss jeden Zeiger verwenden, um eine
physikalische Adresse für
den 32-Byte-NVRAM-Deskriptor
zu erzeugen. Der Inode-Manager muss die gesamten Inhalte des Deskriptors
in den Speicher schreiben, wobei der primäre und/oder sekundäre Zustand
auf ,geschützt' gesetzt wird. Zusätzlich muss
er einen 8-Byte-Sequenznummer zuweisen, die einer mehr entspricht
als dem letzten NVRAM-Puffer, den er schützt. An diesem Punkt sind die
Puffer geschützt
und dem Inode-Manager ist erlaubt, eine Antwort auf die Schreibanforderung
auszugeben.
-
Wenn
die Antwort an den Client gesendet worden ist, wird der Inode-Manager
jeden unreinen Cache-Block mittels einer Block_Release_Dirty-Nachricht
an den Cache-Controller
freigeben. In dieser Nachricht muss der Prozessor angeben, welcher
oder welche NVRAM-Puffer freigegeben werden müssen, wenn der Block gelöscht wird.
Da bis zu zwei NVRAM-Puffer benötigt
werden, um mit einem einzigen Cache-Block durch den Inode-Manager
verknüpft
zu werden, stellt der Block-Release_Dirty-Call genügend Raum
bereit, diese Zeiger durchzugehen. Zusätzlich stellte dieser Call
ein Bit pro NVRAM-Zeiger bereit, um anzugeben, ob der primäre oder
der sekundäre
Bereich des NVRAM-Puffers mit diesem Cache-Block verknüpft werden
muss.
-
Es
ist wichtig, zu bemerken, dass der Cache-Block, welcher mit den
neuen NVRAM-Zeigern
verknüpft worden
ist, bereits die Nachverfolgung anderer aufrechterhalten kann. Deshalb
ist es für
den Cache-Controller notwendig, eine Liste von NVRAM-Zeigern zu
halten, welche Freigabe benötigen,
wenn der Cache-Block gelöscht
wird. Um dies zu erreichen, hält
der Cache-Controller einen separaten Pool bzw. Ansammlung von 8-Byte-Einträgen in einem
Bereich des Cache-RAMs bereit, der die NVRAM-Freigabeliste genannt
wird. Ein Block_Release_Dirty-Call geht ein und der Cache-Controller
wird eine einzelne verbundene Liste von NVRAM-Puffern in diesem
Speicher bilden. Es muss so viele Einträge in dieser Liste geben wie
es NVRAM-Puffer gibt. Diese Liste wird die NVRAM-Freigabeliste genannt,
so wie sie in dem Cache-RAM aufbewahrt wird.
-
Phase 3: Nutzdaten-Freigabe
-
Ausfallanalyse
von Nutzdatenübergabe
bzw. Freigabe Während
dieser Phase treten nur Änderungen an
den NVRAM-Strukturen auf, wenn der Inode-Manager den oder die NVRAM-Deskriptoren
eingibt, um die Schreibdaten zu schützen. Die Statusbits des Deskriptors
sind in seinem Abschlusswort plaziert worden, um sicherzustellen,
dass der Statuswechsel auf ,geschützt' nicht auftreten wird, bis alle anderen
Felder zunächst beschrieben
worden sind. Während
der Deskriptor sich in dem Ungültigkeitszustand
bei Beginn dieser Phase befindet, wird der Deskriptor keinen Kandidaten
zur Wiederherstellung darstellen, bis alle Felder gültige Informationen
enthalten.
-
Beschreibung der Nutzdaten-Freigabe
-
Der
Grund, warum eine Freigabeliste von NVRAM-Puffern hinter den Cache-Puffer
gehalten wird und warum der Server es erlaubt, dass diese Liste
in einer willkürlichen
Reihenfolge erzeugt wird, selbst dann, wenn ein Stromausfall zu
jeder Zeit zu erwarten ist, wird nun beschrieben. Um es dem Server
zu erlauben, verschiedene Software und Hardwaremodule aufzuweisen,
die unabhängig
und gleichzeitig in dem File-System arbeiten, muss genügend Flexibilität vorhanden
sein, um es den Funktionen zu ermöglichen, außerhalb der Reihenfolge abzuschließen. Mit
anderen Worten: Angenommen, ein Cache-Block hat eine Liste von NVRAM-Puffern,
um diese freizugeben, wenn deren Inhalte schließlich auf die Platte geschrieben
werden. Und angenommen, dass diese Liste der Puffer sich in der
folgenden Reihenfolge befand, wobei die Nummer die Reihenfolge wiedergibt,
in welcher die Daten von dem Client angekommen sind: 1-2-5-4-3.
Eingedenk dieser Aussage schrieb der Client an eine Datei 5-mal
sehr schnell in einer Zeile und der Server verarbeitete diese Anforderungen
in einer Weise, dass die 3-te Schreiboperation zuletzt in die Freigabeliste
geschrieben wurde (obwohl die aktuellsten Schreibdaten von der Anforderung
#5 sich eigentlich in dem Cache-Puffer befindet). Falls die Stromzufuhr
verloren gegangen ist, bevor die Freigabeliste bearbeitet worden
ist, würde
es kein Problem machen, weil die NVRAM noch alle 5 NVRAM-Puffer
zur Verfügung
hätten,
und sie in Ordnung bringen würden
und sicherstellten, dass die aktuellsten Daten es zur Platte hin
schaffen. Jedoch, was wäre.
wenn die ersten 3 Einträge
der Freigabeliste von dem NVRAM entfernt worden wären und dann
die Stromzufuhr ausgefallen wäre.
Wenn das System ein Back-Up machte, würde es sehen, dass die Übermittlung
#3 und #4 sich in dem NVRAM befänden
und es würde
sie aus der Platte ausschreiben, wobei fälschlicherweise die aktuellsten Daten
von der Übermittlung
#5 überschrieben
würden.
Dieses Problem wird mit der privaten Liste gelöst, welche durch den Anforderungs-Manager
bereitgestellt wird, wenn die Puffer freigegeben werden.
-
Insbesondere
wird der Cache-Controller informiert, wenn ein Cache-Block gelöscht wird,
durch die Verwendung der Block_Op-Löschnachricht. Wenn dieser Call
empfangen wird, wird der Cache-Controller mit dem Anforderungs-Manager
in Kommunikation treten, um jeden Zeiger, der in dem Status referenziert
ist, freizugeben. Weil der File-Server eine (so genannte) ,multi-threading
processing engine' ist,
gibt es keine Garantie, dass die Reihenfolge der freigegebenen NVRAM-Puffer
dieselbe Reihenfolge ist, in welcher die Anforderungen von dem Netzwerk
ankommen. Deshalb kann der Anforderungs-Manager keine einfache Vorgehensweise
durch Nullung der NVRAM-Deskriptoren durchführen, weil er diese auf die
freie Liste setzt. Falls der Strom ausfällt, während der Chip die unregelmäßigen (,out-of-order')-Deskriptoren zu
der freien Liste zurückführt, würde der
Wiederhersteilungsprozess annehmen, dass die älteren Puffer, welche nicht
befreit worden sind, tatsächlich
die aktuellsten Daten enthalten.
-
Um
die Beschränkung
der Reihenfolge zu vermeiden, gibt der Server die NVRAM-Puffer in
einer kontrollierten Art und Weise frei. Zuerst wird die gesamte
Zeigerliste von dem Cache-Controller an den Anforderungs-Manager
in einer beliebigen Reihenfolge übermittelt.
Während
der Anforderungs-Manager die Zeiger empfängt, wird er den primären oder
sekundären
Bereich (wie durch den Cache-Controller angezeigt) zu dem Freigabestatus ändern, während er
sie in einer privaten Liste miteinander verknüpft. Falls der Anforderungs-Manager
feststellt, dass der gegenüberliegende
Bereich des NVRAM-Zeigers
noch geschützt
ist, reiht er den Zeiger am Kopf bzw. Anfang der privaten Liste
ein. Andernfalls reiht er den Zeiger am Ende der privaten Liste
ein. Nachdem der Cache-Controller
die gesamte Liste der NVRAM-Pointer sendet, um sie freizugeben, wird
der Anforderungs-Manager die neue Liste an den Anfang der gegenwärtigen freien
Liste anhängen
und das NVFREE_HEAD-Wiederherstellungs-Register aktualisieren, um
auf den neuen Kopf bzw. Anfang zu zeigen. Um zu vermeiden. dass
ein NVRAM-Zeiger auf der freien Liste zweimal plaziert wird, muß der Anforderungs-Manager
dann alle die Deskriptoren ausreihen, welche Daten von der freien
Liste geschützt
haben, bevor jede weitere Freigabe von dem Cache-Controller akzeptiert
wird. Er macht dies durch die folgende normale Ausreihungsprozedur.
-
Ausfallanalyse von Nutzdaten-Freigabe
-
Die
erste Änderung
der NVRAM-Strukturen, welche während
der Freigabe-Prozedur auftritt, ist die Erzeugung der privaten Liste.
Warm immer ein Zeiger an den Anfang oder das Ende der privaten Liste
geschrieben wird, werden die Status-Bits auf Freigabe zum selben
Zeitpunkt geändert,
an dem der nächste
Zeiger aktualisiert wird. Während
der Erzeugung der privaten Liste gibt es überhaupt keine Änderungen
an der freien Liste. Deshalb wird, falls die Stromversorgung der
Herstellung der privaten Liste ausfällt, jeder NVRAM-Zeiger hinter
dem neuerlich gelöschten
Cache-Block wiederhergestellt, egal ob er es zu der privaten Liste
hin schafft oder nicht.
-
Die
zweite Änderung
der NVRAM-Strukturen tritt auf, wenn die private Liste zum Anfang
der freien Liste hin verschoben wird. Zu diesem Zeitpunkt, wird
der nächste
Zeiger eines jeden Eintrags am Ende der privaten Liste aktualisiert,
um den gegenwärtigen
freien Kopf bzw. Anfang darzustellen. Der nächste Schritt ist es, das NVFREE_HEAD-Wiederherstellungs-Register
zu aktualisieren, um auf den Anfang der privaten Liste zu zeigen.
Dies verschiebt effizient jeden neuerlich freigegebenen NVRAM-Zeiger
zu der freien Warteschlange zum selben Zeitpunkt. Falls die Stromversorgung
ausfällt,
bevor das NVFREE_HEAD-Wiederherstellungs-Register aktualisiert worden
ist, würde
der Wiederherstellungs-Prozess immer noch die gesamte Liste wiederherstellen,
weil es nicht auf der freien Liste gefunden wird.
-
Stromausfall-Prozedur
-
Bei
Stromausfall wird der Datei-Server alle NVRAM-Aktivitäten elegant
zu einem Abschluss bringen. Der Speicher-Controller, der Daten zu
dem NVRAM sendet, wird aufhören,
jede neue Anforderung von dem Anfoderungsmanager und dem Inode-Manager
zu akzeptieren und wird jeden so genannten ,write-posting' Puffer leeren, den
er hat. Der Leerungsschritt ist wichtig, weil der Anforderungs-Manager
eine Antwort an den Client gesendet haben könnte, nachdem die Schreiboperation
von dem Speicher-Controller akzeptiert worden ist, jedoch bevor
sie tatsächlich
es zu dem NVRAM geschafft hat. Der Speicher-Controller wird dann
einer Abschaltprozedur folgen, welche die Stromversorgung in eine
Batterieabsicherung überführt und
den Speicher in einen Schwachstrom-Modus setzt.
-
Wiederherstellungs-Prozedur
-
Wenn
die Stromversorgung in einem System wiederhergestellt ist, muss
der Anforderungs-Manager deaktiviert
bleiben, bis der gesamte Server bereit ist, neue Anforderungen anzunehmen.
Nachdem die normale Initialisierungsroutine abgeschlossen ist, wird
von dem Inode-Manager erwartet, jeden Deskriptor in dem NVRAM durchzugehen,
um zu bestimmen, welche Puffer Daten geschützt haben und in welcher Reihenfolge
sie empfangen worden sind.
- 1. Absuchen des
gesamten NVRAM-Deskriptor-Raumes nach allen Zeigern, welche einen
Datenbereich aufweisen, der sich in dem ,Freigabe' oder ,geschützt'-Zustand befindet. Platzieren dieser
Bereiche in der ,geschützt'-Liste.
- 2. Auslesen des NVFREE_HEAD-Wiederherstellungs-Registers.
- 3. Verfolgen der verknüpften
Liste der freien Puffer, Entfernen aller Freigabe-Bereiche aus der
geschützten Liste.
- 4. Absuchen der gesamten geschützten Liste und Einordnung
dieser durch Sequenznummern.
-
Nachdem
die letzte Liste der geschützten
Daten bestimmt worden ist, wird der Inode-Manager sich mit dem Cache-Controller
verständigen,
um die aktuellen Inhalte der Festplatten-Blöcke (,subject disk blocks') aus dem Platten-Array
in die Cache-RAM gelesen zu haben. Dann überschreibt er jene Cache-Blöcke mit
den Daten, welche in den NVRAM-Puffern gespeichert sind, wobei er
bei einem Byte-Offset beginnt, welches in den Deskriptoren aufgezeigt
wird. Nachdem alle Daten in die Cache-Blocks kopiert worden sind,
wird er die Daten zurück
auf die Platte schreiben, wobei das File-System auf die aktuellste
Version aktualisiert bzw. updated wird. Zu diesem Zeitpunkt kann
der Server in der Lage sein, neuen Netzwerk-Traffic von seinen Clients
zu empfangen.
-
In
dem bevorzugten Ausführungsbeispiel,
und wie in 5 dargestellt, werden Anforderungen
von Clients an einer 32 Gbps ,backplane' 80 durch eine ,fabric'-Schnittstelle 80 empfangen,
welche das Format der Daten wandelt, die von dem ,backplane' 80 empfangen
werden, in ein Format mit dem der Anforderungs-Warteschleifenmanager 82 arbeiten
kann. Die ,fabric'-Schnittstelle 81 und
der Request bzw. Anforderungs-Warteschleifenmanager 82 bilden
zusammen den Anforderungs-Manager.
Der Anforderungs-Warteschleifen-Manager 82 schreibt die
Daten an den DRAM-Controller 83, der dann die Daten an
den externen gemeinsamen DRAM-Speicher 92 und
letztendlich die NVRAM kommuniziert. Der Anforderungs-Warteschleifenmanager 82 stellt
auch Informationen für
den ZBT-Controller 84 bereit, welche als Schnittstelle
zu dem externen gemeinsamen SRAM-Speicher 85 dient.
-
Der
Anforderungs-Warteschleifenmanager 82 steht in Kommunikation
mit dem Nachrichten-Warteschleifenmanager 85, welcher als
Knotenpunkt für
alle Nachrichten zwischen den verschiedenen Komponenten des Systems
dient. Nachrichten von dem Nachrichten-Warteschleifenmanager 85 werden
dem ,fast path uP-Schnittstellenmanager 86 bereitgestellt,
welcher mit dem externen mode-Manager und dem Platten-Manager kommuniziert.
Der Platten-Manager wird aus einem BMAP-Lese-Prozessor und einem
BMAP-Schreibprozessor gebildet. Der Platten-Manager ist in einen
Leseprozessor und einen Schreibprozessor zerlegt, um die Arbeitslast
besser zu verteilen. Der Nachrichten-Warteschleifen-Manager 85 steht
in Kommunikation mit dem Cache-Controller, welcher wiederum die
Schnittstelle mit dem externen Cache-Status DRAM 95 bildet.
-
Der
Nachrichten-Warteschleifen-Controller 85 und der Cache-Daten
DRAM-Controller 93 stehen in Verbindung mit dem Verzeichnismanager 87,
um Informationen bezüglich Daten
zu erhalten, welche in externen Speichern gespeichert sind. Der
Nachrichten-Warteschleifen-Controller 85 steht
auch mit einer slow-path-Schnittstelle 88 in Verbindung,
die mit einem externen ,blade control'-Prozessor 89 zur Wartung des Systems
in Verbindung steht. Der ,fiber channel'-Manager 90 steht in Verbindung
mit ,fiber channels' 91,
welche sich außerhalb
des Chips 94 für
die Übertragung
von Daten zu und von der Platte und Inodes erstrecken. Der Anforderungs-Warteschleifenmanager 82 steht
auch in Verbindung mit dem Cache-Data DRAM-Controller 93,
der eine Schnittstelle zu dem Cache-Datenspeicher 96 bildet.
-
Obwohl
die Erfindung im Detail in den vorgenannten Ausführungsformen zum Zwecke der
Veranschaulichung beschrieben worden ist, versteht es sich, dass
solche Details lediglich solchem Zwecke dienen und dass Variationen
hiervon durch Fachleute ausgeführt
werden können,
ohne vom Schutzumfang der Erfindung anzuweichen, es sei dem, dass
es durch die nachfolgenden Ansprüche
beschrieben wird.