DE60016866T2

DE60016866T2 - Verfahren und vorrichtung zur behandlung von datenverfälschung und gemeinsam genutzte platten im kontext von datensicherung, -benützung und wiederherstellung

Info

Publication number: DE60016866T2
Application number: DE60016866T
Authority: DE
Inventors: D. Eric SCHNEIDER; J. Michael GUSTAFSON; J. Daniel HAGLER
Original assignee: Symantec Corp
Current assignee: Gen Digital Inc
Priority date: 1999-04-23
Filing date: 2000-04-24
Publication date: 2005-12-22
Anticipated expiration: 2020-04-25
Also published as: ATE285602T1; WO2000065447A1; DE60016866D1; EP1090348A1; EP1090348B1; JP3984789B2; JP2002543493A; AU4486200A

Description

Technisches Gebiet der Erfindung
Die vorliegende Erfindung betrifft allgemein die Speicherung digitaler Daten und insbesondere Verfahren und Einrichtungen zur Sicherung und Wiederherstellung von Daten, die von einem digitalen Computer gespeichert wurden.
Hintergrund der Erfindung
Die Behandlung der Umleitung von Schreib-Operationen auf eine Platte zur Erhaltung von Daten, die überschrieben werden, umfasst in einem Ausführungsbeispiel des Systems, das in der US-Patentanmeldung mit dem Aktenzeichen 09/105,733 beschrieben wurde, die am 26. Juni 1998 mit dem Titel „METHOD, SOFTWARE AND APPARATUS FOR SAVING, USING AND RECOVERING DATA" (nachstehend als –US '733– bezeichnet) eingereicht wurde und mit der Anmeldung WO-A-99/12101 übereinstimmt, zwei Elemente: ein Vorgeschichte-Ringpuffersystem und eine Haupt-Speicherbelegungstabelle. Der Vorgeschichtepuffer empfing zunächst die umgeleiteten, neu geschriebenen Daten, während die Haupt-Speicherbelegungstabelle die tatsächliche momentane Speicherstelle der Daten einer vorgegebenen Seite verfolgte, und zwar aus Sicht des Betriebssystems(in Unkenntnis der Umleitung). Wenn es die Zeit erlaubte, wurden im Temp-Verfahren Austauschungen zum Vertauschen der umgeleiteten Daten und der „überschriebenen" historischen Daten mit ihren entsprechenden, nicht abgebildeten Speicherstellen der Festplatte ausgeführt. Das Always-Verfahren minimierte das Austauschen durch ein Umleiten der neu geschriebenen Daten zu alternativen physikalischen Speicherstellen der Platte, in denen die Daten allgemein belassen wurden. Folglich ist eine langfristige Neuabbildung erforderlich.
US '733 vergegenwärtigt, daß in einigen Situationen die in den Temp- und Always-Verfahren erforderlichen Austauschaktivi täten gegenüber der Regenerierung der historischen Daten in Verzug geraten könnten. Mit anderen Worten, der Anwender überschreibt so viele Daten, daß die Situation entsteht, in der Speicherstelle X sehr alte historische Daten HD enthält, die den Austausch zur Speicherstelle Y erwarten, zu der sie tatsächlich gehören (für eine optimale Organisation – d.h. eng in Beziehung stehende Daten) und ein Überschreiben der gleichen Speicherstelle mit neuen Daten ND auftritt. Da die neuen Daten ND zum Überschreiben der alten historischen Daten HD umgeleitet werden, die sich normalerweise an der Speicherstelle Y befinden würden, sich jedoch temporär an der Speicherstelle X befinden, beschrieb US '733 einen Prozess, in dem die ND an die Speicherstelle X geschrieben und die Speicherbelegungstabellen entsprechend aktualisiert werden. Dieser Prozess erfordert ziemlich komplex miteinander verknüpfte Speicherbelegungstabellen. US '733 beschreibt die Verwendung dauerhafter und vorübergehender Seiten zur Verwaltung miteinander verbundener Speicherbelegungstabellen mittels einer Steuerung durch eine Vermittlungsseite.
In einer perfekten Umgebung würden die Methoden von US '733 sehr gut funktionieren. Die praktische Erfahrung hat jedoch eine potentielle Schwäche in US '733 aufgedeckt. Dies besteht darin, daß viele Personalcomputer einen fehlerhaften Code und gestörte Hardware enthalten, die eine Datenverfälschung zur Folge haben.
Zusammenfassung der Erfindung
Gemäß der vorliegenden Erfindung wird ein System und Verfahren zur Verwaltung eines Protokolls der Änderungen an Daten auf einem Aufzeichnungsmedium und zur Gewährleistung der Rekonstruktion des Zustandes des Mediums zu einem vorherigen Zeitpunkt bereitgestellt. Zur Weiterentwicklung und Verbesserung des Prozesses werden verschiedene alternative Ausführungsbeispiele bereitgestellt. Dazu gehören eine Verwaltung von zwei Kopien im RAM der Daten, die zum Erfassen einer Verfälschung vor der Übertragung an das Aufzeichnungsmedium verglichen werden, eine Teilung von logischem Schutz und Darstellung, eine Maskierung der Platte zum Schutz gegen inkompatible Software, die Durchführung einer Flush-Operation eines Schreib-Caches nach der Sicherstellung des Vorübergehens einer bestimmten Zeitdauer, die Durchführung einer Flush-Operation eines Schreib-Caches nach der Sicherstellung des Vorübergehens einer bestimmten freien Zeitdauer und die bedarfsweisen Einfügung von Verzögerungen, eine Einfügung sicherer Zeitpunkte nach einem Abfall der Rate der Plattenaktivität, eine periodische Einfügung sicherer Zeitpunkte, die Durchführung einer Flush-Operation des gesamten OS-Caches nach einer Erfassung der Notwendigkeit der Errichtung eines sicheren Zeitpunktes für einen Anwender, eine Aussonderung von Anwenderaktivität durch die Beobachtung von Verzeichnissen und Dateien oder die Verwendung von komplex verknüpften Datenstrukturen zur Ausführung der Engine [Maschine], wobei derartige Datenstrukturen im Wesentlichen von aufeinanderfolgend organisierten Tabellen im Falle einer Verfälschung rekonstruiert werden können.
Diese Aufgaben werden in vorteilhafter Art und Weise hauptsächlich durch die Anwendung der in den unabhängigen Ansprüchen 1 und 8 niedergelegten Merkmale gelöst.
Kurzbeschreibung der Zeichnungen
1 veranschaulicht den Anfangszustand eines New-Temp-Verfahrens gemäß der vorliegenden Erfindung.
2 veranschaulicht das Geschehen nachdem das Betriebssystem im Beispiel von 1 die Daten „d2a" zur Speicherstelle 2 schreibt.
3 veranschaulicht einen sicheren Zeitpunkt, der gemäß einem beispielhaften Ausführungsbeispiel der Erfindung eingerichtet wurde.
4 veranschaulicht drei weitere Schreib-Operationen gemäß einem beispielhaften Ausführungsbeispiel der Erfindung.
5 und 6 zeigen Austauschungen, die gemäß einem beispielhaften Ausführungsbeispiel der Erfindung ausgeführt werden, wobei umgeleitete und historische Daten ausgetauscht werden und die Speicherbelegungstabelle entsprechend aktualisiert wird.
Das Problem der Datenverfälschung
Die Beschaffenheit des Problems eines fehlerhaften Codes betrifft einen Code, der wahrscheinlich nicht Teil der Software ist, die US '733 (Engine) ausführt, sondern Teil des Betriebssystems von Gerätetreibern oder Anwendungen. Ein „Bug" [Programmfehler] kann eine vorsätzliche Böswilligkeit durch Viren umfassen. Ungeachtet der Quelle des Bugs ist das Ergebnis die Verfälschung der mit der Engine verbundenen Logik (Code) und/oder Daten. Eine massive Verfälschung bewirkt eigentlich nicht die größten Schwierigkeiten. Eine massive Verfälschung tendiert dazu, einen Computer schnell funktionsunfähig zu machen, insbesondere bevor sich die Verfälschung vom internen Speicher des Computers (RAM) auf die Platte ausgebreitet hat. Die Lösung ist in einem derartigen Fall, den Computer einfach neu zu starten. Da die Platte nicht betroffen war, wird der RAM von den unverfälschten Daten der Platte neu initialisiert. Eine kleine Verfälschung kann jedoch einen verheerenden Schaden anrichten, der viel ernster ist. Ein üblicher Bug in einer Software ist ein falsch referenzierender Zeiger [wild pointer] (oder Array-Index), der zur Verfälschung einiger weniger zufälliger Bytes des RAM führt (d.h. die Speicherstelle der betroffenen Bytes im RAM ist nicht vorhersagbar).
Selbst wenn ein Code nur geringfügig verfälscht wird, ist der Effekt im Allgemeinen katastrophal – ein Code ist eine Abfolge von Computeranweisungen unterschiedlicher Längen (Anzahl von Bytes). Wenn eine Anweisung durch die Verwendung eines falsch referenzierenden Zeigers „getroffen" (geändert) wird, wird nicht nur die Aktion dieser Anweisung geändert, sondern im Allgemeinen alle ihr nachfolgenden. Das ergibt sich daraus, daß der Start der nächsten Anweisung falsch angeordnet ist, wenn der Effekt der zufälligen Änderung einer Anweisung in einer Änderung ihrer Länge besteht (die Anzahl der Bytes aus der die Anweisung besteht). Folglich sind alle nachfolgenden Anweisungen üblicherweise zufälliger Ausschuss – Teile anderer, nacheinander falsch interpretierter Anweisungen – und das Ergebnis ist, daß der momentane Prozess allgemein schnell funktionsunfähig wird, wenn der Computer eine einzelne verfälschte Anweisung ausführt. Betriebssysteme versuchen Prozesse auf einem Computer zu isolieren (unter Verwendung von in die Hardware der Mikroprozessoren eingebauten Mechanismen), so daß, wenn ein Prozess fehlschlägt, sein Schaden eingegrenzt und der Prozess abgebrochen werden kann. Eine übliche Nachricht unter Windows 95 ist „eine allgemeine Schutzverletzung ist aufgetreten", nach der irgendeine Anwendung oder Komponente des Betriebssystems beendet wird. Wenn jedoch eine unbedingt notwendige Komponente des Betriebssystems, wie zum Beispiel die Engine, abgebrochen wird, wird das gesamte System zum größten Teil funktionsunfähig. Folglich ist das Verhalten eines Computers nach einer geringfügigen Verfälschung des Codes der Engine sehr ähnlich einer massiven Verfälschung. Wenn der betroffene Code aufgerufen (ausgeführt) wird, stürzt der Computer ab und zwar wahrscheinlich, bevor eine Verfälschung auf der Platte verbreitet wird.
Eine geringfügige Verfälschung ist schlimmer
Das wirkliche Problem tritt auf, wenn eine geringfügige Verfälschung der Daten der Engine auftritt. Dies ist sehr viel gefährlicher, da es dazu führt, daß die Logik der Engine die Platte basierend auf den verfälschten Daten (im RAM) modifi ziert und somit die Verfälschung auf der Platte verbreitet. Sobald dies geschieht, sind selbst nach dem Neustart des Computers die Daten der Engine auf der Platte verfälscht. Folglich sind die wesentlichen Funktionen der Engine im Allgemeinen verloren, vom Lokalisieren, wohin die momentanen Daten des Anwenders abgebildet wurden, bis zu ihrer Fähigkeit, ein Abbild der Platte darzustellen, wie es in der Vergangenheit war. Dies liegt zum Teil daran, daß die Techniken zum Neuabbilden der Platte die Daten auf der Platte durcheinander bringen und folglich die Daten ohne die Speicherbelegungstabellen im Wesentlichen bedeutungslos sind.
Zu allem Übel kann die Verfälschung der Daten der Engine auf der Platte ihre Ursache noch nicht einmal im RAM haben. In der realen Praxis kann eine Verfälschung in die Kommunikation zwischen dem Hauptmikroprozessor des Computers und dem Plattencontroller eingebracht werden. Die Speicherstelle, zu der eine Seite zu schreiben oder von der eine zu lesen ist, kann verstümmelt oder die Daten im Kommunikationsprozess können verfälscht werden. Über eine ausgedehnte Zeitdauer kann eine kleine Menge von auf einer Platte gespeicherten Daten mangelhaft werden (eine mangelhafte Seite). Oder die Verwendung von mit der Engine inkompatibler Software, die jedoch die Fähigkeit besitzt, direkt auf die Platte zuzugreifen, kann die Daten der Engine verfälschen (wie zum Beispiel ein Platten-„Doktor"-Dienstprogramm).
Noch einmal, es sind nicht die massiven Hardwarefehler, die ein Problem sind. Wenn die Festplatte eines Computers vollständig die Funktion versagt, gibt es nicht viel, was getan werden kann (vom Standpunkt der Software). Im anderen Extrem ist es jedoch unangemessen, einer einzelnen oder seltenen Störung zu gestatten, die gesamten Informationen der Platte unbrauchbar zu machen, wenn die Mehrheit der Daten der Platte unversehrt ist und die Platte im Allgemeinen größtenteils immer noch funktionsfähig ist.
Steuerung der Reihenfolge, in der die Daten geschrieben werden (Schreib-Cache)
Ein letztes interessantes, in der Technik von US '733 inhärentes Problem ist die Notwendigkeit der Steuerung der Reihenfolge, in der die Daten auf eine Platte geschrieben werden. Wenn zum Beispiel der Übergang von einem stabilen Zustand zu einem anderen ausgeführt wird, werden Übergangsdaten auf die Platte geschrieben (mit einer Flush-Operation) und danach die Vermittlungsseite aktualisiert. Im Bestreben ihr Leistungsverhalten zu verbessern, umfassen moderne Plattenlaufwerke jetzt jedoch Schreib-Caches. Diese Schreib-Caches puffern Schreib-Operationen und übergeben die Daten dem Plattenmedium in einer anderen, als der geschriebenen Reihenfolge. Indem zum Beispiel dem Plattencontroller gestattet wird, die Daten in einer Reihenfolge zu schreiben, die die Bewegung des Plattenkopfes reduziert, wird der gesamte Schreibprozess beschleunigt. Jetzt kann jedoch die Vermittlungsseite auf der Platte vor den Daten aktualisiert worden sein, von denen angenommen wird, daß sie bereits auf der Platte vorhanden sind (sie warten immer noch darauf, geschrieben zu werden). Im Fall einer Netzunterbrechung wird der sichere Übergang von einem stabilen Zustand zu einem anderen unbrauchbar gemacht.
Es stellt sich heraus, daß es Befehle gibt, die zur Deaktivierung einer derartigen Schreib-Cache-Optimierung zu Plattenlaufwerken gesendet werden können. Diese deaktivieren jedoch auch andere nützliche Optimierungen und folglich ergibt sich eine erhebliche Herabsetzung des Leistungsverhaltens. Einige Platten unterstützen die Verwendung eines Flush-Befehls, um speziell eine Flush-Operation des Schreib-Caches durchzuführen. Diese Befehle sind jedoch nicht einfach verfügbar. Mit anderen Worten, in einem heutigen Computer gibt es im BIOS Standardmittel zum Lesen und Schreiben von einer Platte. Aber es gibt kein Standardmittel zur Durchführung einer Flush-Operation des Schreib-Caches. Ungeachtet dessen, ob ein Plattenlaufwerk eines Computers einen Flush-Befehl unterstützt, gibt es folglich keine Möglichkeit für die Engine eine Flush-Operation einfach zu initiieren, da die Engine die Standardschnittstelle des BIOS verwendet. Sie müsste sich direkt mit der Platte unterhalten und folglich eine spezielle Hardwarekenntnis aufweisen, was vom Standpunkt eines allgemeinen Programms aus nicht möglich ist, von dem erwartet wird, daß es auf jedem Computer läuft. Allgemein hat der Computerhersteller einen bestimmten Festplattentyp mit einem BIOS eng verbunden, dem bekannt ist, wie dieser Plattentyp zu steuern ist. Jede nachfolgende Software verlässt sich im Allgemeinen auf die durch das BIOS bereitgestellten Schnittstellen, um sich mit der Platte zu unterhalten – sei es eine SCSI, eine IDE oder eine andere –. Die derzeitige Schnittstelle umfasst keinen Flush-Befehl. Ohne zu versuchen, spezialisiertes Platten (Hardware)- Wissen in die Engine einzubauen, würde deshalb ein verbesserter Aufbau der Engine das Vorhandensein eines Schreib-Caches ohne das Erfordernis eines Verfahren zur Durchführung einer Flush-Operation erleichtern. Dies impliziert, daß die Engine berücksichtigen muss, daß zu einem Plattencontroller geschriebene Daten dem Plattenmedium tatsächlich in einer anderen Reihenfolge übergeben werden können. Dessen ungeachtet muss die Engine zur Gewährleistung der Wiederherstellung nach einem Absturz zu jedem Zeitpunkt ihre Daten-Integrität auf der Platte aufrechterhalten.
Die Anforderungen einer robusten Engine
Zusammengefasst, eine Engine muss mit der Datenverfälschung sowohl im RAM als auch auf der Platte, die von verschiedenen Quellen in der Computerwelt ausgelöst wird, geschickt umgehen. Sie muss die Verbreitung verfälschter RAM- Daten zu ihren plattenbasierten Daten (z.B. falsch referenzierende Zeiger) vermeiden. Sie muss von einer nur gelegentlichen Verfälschung wiederherstellen, die von der Platte entstammt (z.B. verfälschte Übertragungen, fehlgeleitete Schreib- oder Leseoperationen oder mangelhaft gewordene Seiten). Sie muss stabile Datenstrukturen aufrechterhalten und in der Lage sein, sie im Fall eines Absturzes wieder herzustellen, selbst wenn es unmittelbar vor dem Absturz nur Teile der zum Plattencontroller geschriebenen Daten tatsächlich schafften (andere Teile waren verloren, haben es nicht aus dem Schreib-Cache herausgeschafft). Ohne besondere Berücksichtigung dieser Sachverhalte können die Techniken von US '733 infolge der Verfälschung der wesentlichen Daten der Engine zu einem vollständigen Datenverlust führen.
Bevor mit der vorliegenden Erfindung fortgesetzt wird, die auf diese Sachverhalte eingeht, kann man sich fragen, wie es derzeitigen Computern gelingt, unter diesen Umständen im Allgemeinen zu funktionieren. Die Antwort liegt teilweise in einem ScanDisk genannten Programm, das immer automatisch abläuft, wenn ein auf Windows basierender Computer startet und begründet annimmt, daß er zuvor nicht in einer ordnungsgemäßen Art und Weise heruntergefahren wurde. Oder, der Anwender kann das Programm manuell starten, wenn er oder sie vermutet, daß sie „Plattenprobleme" haben. ScanDisk prüft die plattenbasierten Datenstrukturen des Betriebssystems und repariert sie nach bestem Vermögen. Der Hauptpunkt ist, daß ScanDisk keinen Schaden rückgängig macht oder zu einem vorher bekannten mangelfreien Zustand zurückkehrt. Es korrigiert und passt einfach verschiedene Verknüpfungen an, bis die Datenstrukturen des Betriebssystems wieder verwendbar sind. Oft ist eine gewisse Datenmenge verloren oder verfälscht – d.h. Teile von Dateien sind verloren oder geändert oder sogar ganze Dateien verschwinden. Es gibt jedoch eine Menge Dateien auf einem Compu ter und viele werden nie oder selten verwendet. Deshalb kann eine signifikante Menge von Verfälschungen auftreten, bevor ein Computer ernsthaft funktionsunfähig wird. Indem über die Zeit verschiedene Teile des Systems langsam verfälscht werden, werden folglich derzeitige Computer mehr oder weniger „krank". Es ist den Computeranwendern nicht unbekannt, ihre Platte periodisch zu bereinigen und das Betriebssystem, ihre Anwendungen und Daten neu zu installieren.
Die Zusicherung, zeitlich Zurückzugehen
Dieser Prozess der graduellen Verfälschung steht im Widerspruch zu den Zusicherungen der Engine. Das Ziel der Engine ist es, die Platte genau so zurückzugeben, wie sie zu einem vorherigen Zeitpunkt war. Folglich muss sie immun gegen eine auftretende graduelle Verfälschung sein, die momentan von ScanDisk (oder einem ähnlichem Reparaturdienstprogramm) nach bestem Vermögen korrigiert wird.
In einer perfekteren Umgebung würde ein Betriebssystem die Engine und ihre Daten vor falsch referenzierenden Zeigern und Viren schützen und mit ein wenig Beachtung der Datenredundanz auf der Platte (um vor einer gelegentlichen mangelhaften Übertragung zu schützen) würden die Techniken von US '733 genügen. Betriebssysteme müssen jedoch auf ihrer untersten Ebene erweiterbar sein. Folglich ist es schwierig, sie so auszuführen, daß sie einen Gerätetreiber vor einem anderen schützen. Darüber hinaus ist üblicherweise ein Betriebssystem ein sehr großes Programm und als solches ist es schwierig, jeden Bug daraus zu entfernen.
Es mag den Anschein haben, daß alle Programme einen „perfekten" Schutz vor anderen verlangen würden. Tatsächlich versucht das Betriebssystem dies unter Verwendung der in den Mikroprozessor eingebauten Hardwaremittel auszuführen (wie zum Beispiel Interrupts, um einem Programm die Steuerung zu entziehen, und Speicherschutzmechanismen, um verirrte Schreib- Operationen abzufangen). Allerdings muss das Betriebssystem zur gleichen Zeit den Schutz mit der Notwendigkeit der Effizienz ausgleichen. Effizienter Code tendiert dazu, keine Belastung von Schutzabgrenzungen aufweisen zu wollen (es erfordert Zeit, konstant einen Prozess vor einem anderen zu schützen). Die Engine ist jedoch nicht nur ein anderes Programm. Wenn Dinge fehlschlagen, ist es ihre Aufgabe, dem Computer zu gestatten, neu zu starten und alles auf irgendeinen besseren Zeitpunkt zurückzusetzen. Diese Rückfallposition muss geschützt werden. Ein Anwender versteht im Allgemeinen, daß ein Programm im Rahmen des Computer-RAM's abläuft und erwartet oder wünscht zumindest, daß bei Neustart des Computers der Inhalt der Platte intakt sein sollte. Es wird deshalb die Auffassung vertreten, daß der Schutz der Engine und des Plattensystems eine besondere Hardware und/oder Techniken oberhalb der vereinbarten, durch das Betriebssystem verfügbaren Ebene rechtfertigt.
Das Folgende ist eine Zusammenfassung der Problemarten, die eine Engine behandeln muss:

• Eine Datenverfälschung durch einen falsch referenzierenden Zeiger
• Das Lesen verfälschter Daten von der Platte (mangelhafte Übertragung, mangelhafte Seite, etc.)
• Die Verwendung einer inkompatiblen Software, die direkt auf die Platte zugreift

US '733 sah einen Schutz der Engine und ihrer Daten durch die Bereitstellung besonderer Hardware im Hauptmikroprozessor (Firewall [Zugangsschutzsystem]) und/oder der Hauptplatine oder sogar durch eine Verschiebung der Engine zum Computer im Plattencontroller vor. Dies würde das Problem eines falsch referenzierenden Zeigers beseitigen (unter der Annahme, das die Engine frei von Bugs war) und einen direkten Zugriff einer inkompatible Software auf die Platte verhindern. Derzeit existieren jedoch bereits Millionen von Computern, für die eine Modifikation der Hardware keine Option darstellt. Die vorliegende Erfindung bietet Lösungen an, die auf den Prinzipien der Datenredundanz basieren.
Vervielfältigung der RAM-Daten zur Erfassung einer Verfälschung
Um verirrte Schreib-Operationen bis einschließlich falsch referenzierende Zeiger (oder irgendwelche anderen Mittel) zu behandeln, vervielfältigt die Engine der vorliegenden Erfindung alle wichtigsten Datenstrukturen im RAM. Für diejenigen, die mit auf der Platte gespeicherten und im Cache im RAM enthaltenen Daten übereinstimmen, wird die Speicherstelle der Daten auf der Platte in die Daten einbezogen. Der kritische Moment, bei dem auf die sonst gültige Plattenabbildung eine Verfälschung eingebracht werden kann, ist unmittelbar bevor die im Cache aufgenommenen Daten auf die Platte zurückgeschrieben werden. Deshalb werden unmittelbar vor der Schreib-Operation beide Kopien im RAM verglichen, um sicherzustellen, daß sie noch anzeigen, daß sie dem vorgesehenen Bestimmungsort auf der Platte zugeordnet sind und ihre Daten übereinstimmen. Sollte der Abgleich fehlschlagen, ist irgendein (RAM) verfälschendes Element tätig. Es können zusätzliche Techniken eingesetzt werden, die Verfälschung zu identifizieren und zu korrigieren. Die günstigste Vorgehensweise ist jedoch, den Anwender zu warnen und das System neu zu starten. Sobald eine Verfälschung erfasst wurde, hält man das System als Ganzes nicht für vertrauenswürdig. Die Wahrscheinlichkeit ist zu groß, daß eine weitere Verarbeitung zur Verbreitung einer ernsthaften Verfälschung auf der Platte führen wird, von der es keine Wiederherstellung gibt. Eine weniger durchgreifende Reaktion ist es, alle weiteren Versuche der Modifikation der Platte zu blockieren, jedoch den Anwender zu warnen und fortzusetzen, dem System zu gestatten, weiterzuarbeiten. Während dieser Zeit kann der Anwender versuchen, Daten auf alternative Speichereinrichtungen zu speichern (z.B, sein Textverarbeitungsdokument auf eine Diskette zu speichern).
Unter Berücksichtigung der Tatsache, daß Computer unter der Verwendung großer Mengen komplexer, durch viele verschiedene Hersteller bereitgestellte Software laufen, ist es fast sicher, daß gelegentlich verirrte Schreib-Operationen auftreten werden. Unter Berücksichtigung, daß sie sehr großer Platten neu abbildet, ist die von einer Engine eingesetzte Datenmenge im Vergleich mit dem Adressraum des Mikroprozessors erheblich (Megabytes von RAM). In Ermangelung eines Hardwareschutzes gibt es deshalb eine begründete Wahrscheinlichkeit, daß die Daten der Engine gelegentlich verfälscht sind. Zum Beispiel gibt es bei einem Mikroprozessor mit einem 32-Bit Adressraum (4096M), in dem die Engine zwei Megabyte (2M) verwendet, eine Chance von eins zu zweitausend, daß eine verirrte Schreib-Operation die Daten der Engine treffen wird. Jedoch ist die Wahrscheinlichkeit äußerst gering, daß zwei verirrte Schreib-Operationen beide redundanten Kopien der Daten der Engine treffen, die gleiche Änderung ausführen und dasjenige, was auch immer die Verfälschung ausführt, nicht fortsetzen wird, eine massive Verfälschung auszuführen.
Sobald die Engine beide Kopien im RAM gegeneinander validiert hat, schreibt sie die Daten auf die Platte. Zur Sicherstellung einer erfolgreichen Übertragung der Daten zum Plattencontroller, könnte die Engine die Daten unmittelbar zurücklesen und überprüfen. Beide Kopien wurden zu verschiedenen Speicherstellen auf der Platte geschrieben, um den plattenbasierten Daten ein Redundanzniveau hinzuzufügen. Sollte in der Zukunft die Platte aus irgendwelchen Gründen fehlschlagen, eine Kopie zurückzuholen, ist deshalb eine zweite Kopie verfügbar. Das Sicherstellen der Daten-Integrität auf der Platte durch eine Redundanz ist ein sehr bekanntes Prinzip. Es wird zum Beispiel in RAID-Systemen verwendet. In diesem Fall ist die Redundanz jedoch auf zwei, im Allgemeinen auf dem gleichen physikalischen Laufwerk angeordnete Kopien beschränkt.
Aufteilung der Engine
Die beste Lösung zum Schutz der Engine und ihrer Daten wurde hier und in US '733 beschrieben. Sie besteht aus der Bereitstellung eines Hardwareschutzes und der Unterbringung der Engine auf der Hauptplatine (unter Verwendung des Hauptmikroprozessors) oder im Plattencontroller. In Anbetracht der beträchtlichen Anforderungen an den RAM und die Verarbeitungszeit wurde eingewandt; daß der ideale Platz für die Engine auf der Hauptplatine (und nicht auf dem Plattencontroller) ist. Die Engine führt jedoch in Wirklichkeit zwei etwas separate Funktionen aus: sie verwaltet die Wiederverwendung von historischen Daten und bildet die Platte neu ab. Durch das Neuabbilden stellt die Engine dem Betriebssystem verschiedene „Ansichten" der Platte dar. Es werden sowohl die augenblickliche Abbildung als auch die auf der Vergangenheit beruhenden Zustände gezeigt. Sollten jedoch das Neuabbilden und die Ansichten der Platte temporär verfälscht werden, ist dies akzeptabel, solange der Anwender den Computer neu starten kann und ihm (angemessen) garantiert werden kann, daß die Platte und die Fähigkeit, zeitlich zurückzugehen, gesichert ist. Die Argumentation ist diese: es ist ohne Bedeutung, ob eine Anwendung oder das Betriebssystem oder sogar bestimmte Teile der Engine verfälscht sind, wenn das Endergebnis das Gleiche ist – – der Anwender sieht oder erlebt unerwartete Ergebnisse, die nur durch einen Neustart des Computers „beseitigt" werden können.
Folglich ist es möglich, einige Funktionen der Engine zwischen einem ungeschützten Hauptprozessor (und Hauptplatine) und dem Plattencontroller aufzuteilen. Die Speicher- und Ver arbeitungsintensiven Aufgaben, wie das Neuabbilden, werden dem Hauptprozessor überlassen (der die Leistung aufweist), während die weniger anspruchsvolle Logik dem Plattencontroller hinzugefügt wird, um die Datenstrukturen der Engine zu schützen und zu verwalten. Der ungeschützte Teil der Engine wird OSfilter und der Teil im Plattencontroller wird Enforcer [Vollstrecker] genannt. Folglich liest der Hauptprozessor gestützte OSfilter, der das Neuabbilden behandelt, Daten vom Plattencontroller gestützten Enforcer. Es sind die Informationen, die zur Erzeugung und Verwaltung der Speicherbelegungstabellen für die Darstellung verschiedener Ansichten an das Betriebssystem notwendig sind. Sobald Daten vom Betriebssystem geschrieben werden, wird vom Enforcer zugewiesen und sicherstellt, daß die neuen Daten zu anderen Speicherstellen auf der Platte gelangen. Wenn jedoch die neuen Daten umgeleitet werden, wird der OSfilter über die neuen Speicherstellen informiert und passt entsprechend seine Speicherbelegungstabellen an. Im Falle einer Verfälschung der Daten des OSfilters kann der Anwender den Computer neu starten und der OSfilter stellt seine Daten von den durch den Enforcer bereitgestellten wieder her.
Wenn ein Plattencontroller auf die Ausführung der Enforcer-Funktion erweitert wurde, ändern sich die vom Plattencontroller (Enforcer) angeforderten und durchgeführten Plattenoperationen gegenüber den normalen Anforderungen zum Lesen und Schreiben einer Seite. Die Leseanforderung bleibt unverändert, da es keine Veranlassung (*) gibt, die Daten der Engine und alte historische Daten vor dem Lesen zu schützen. Die Schreib-Anforderung impliziert jetzt jedoch, daß der Enforcer die tatsächliche Schreib-Operation zu einer anderen Speicherstelle umleiten und den OSfilter über diese neue Speicherstelle informieren wird. Es ist die Aufgabe des OSfilters, daran zu denken, daß es die Speicherstelle dahin neu abbilden muss, wohin die Schreib-Operation umgeleitet wurde, wenn das Betriebssystem in Zukunft die gerade geschriebene Speicherstelle liest. Es gibt verschiedene Algorithmen zur Bestimmung wohin eine Schreib-Operation umzuleiten ist. Diese wurden in den Temp- und Always-Verfahren von US '733 erörtert. In beiden Fällen ist es wahrscheinlich, daß später die anfängliche Speicherstelle, zu der eine Schreib-Operation umgeleitet wurde, aus Leistungsgründen aktualisiert wird. Diese Neuordnung der Platte wird durch einen Austauschprozess ausgeführt. Da dieser Prozess das Lesen und Schreiben momentaner und historischer Daten sowie das Aktualisieren der auf der Platte basierenden Datenstrukturen der Engine einschließt, wird er im Enforcer ausgeführt.
Der Anwender kann aus Sicherheitsgründen den Schutz alter historischer Zustände der Platte vor einer nicht autorisierten Ansicht wünschen. Vertrauliche Informationen auf der Platte können zu einem Zeitpunkt in der Vergangenheit gelöscht oder verschlüsselt worden sein und es ist wichtig, den Zugriff vor diesem Zeitpunkt zu steuern.
Der OSfilter kann die Speicherung seiner Speicherbelegungstabellen auf die Platte anfordern, obwohl sie aus den durch den Enforcer bereitgestellten Daten rekonstruiert werden können. Deshalb muss der Enforcer einen Zugriff auf eine gewisse Menge halbtemporären Plattenspeicherraums bereitstellen – d.h. der OSfilter speichert seine Datenstrukturen auf der Platte. Falls sie verfälscht erscheinen, werden sie von den geschützten Daten des Enforcers wiederhergestellt. Ein Befehl zum Herunterfahren informiert den Enforcer, daß alle halbtemporären Daten des OSfilters herausgeschrieben woden sind. In diesem Befehl liefert der OSfilter die Speicherstelle seiner Root-Seite [Stamm-Seite] zu seinen Datenstrukturen zur sicheren Aufbewahrung. Eine besondere Leseanforderung gestattet dem OSfilter „Header"-Informationen [Kopfteil-Informationen) zu erhalten, die ihn zu den Nur-Lese-Datenstrukturen des Enforcers leiten, von denen er seine Speicherbelegungstabellen wiederherstellen kann. Diese Header-Seite umfasst die durch das OSfilter unmittelbar vor dem letzten Herunterfahren gelieferte halbtemporäre Root-Speicherstelle oder wird als Null zurückgegeben, wenn zuvor ein Absturz aufgetreten ist.
Zusammengefasst, ein auf einem Enforcer basierender Plattencontroller würde unter anderem die folgenden Grundoperationen akzeptieren. Zusätzliche Operationen, wie zum Beispiel eine Unterstützung des Schutzes gegen ein schnelles Überlaufen des Vorgeschichtepuffers (d.h. Sicherstellen, das eine gewisse minimale Distanz zur Vergangenheit aufrechterhalten wird) und die Verriegelung von historischen Daten, die sich auf eine oder mehrere SOSD-Abbildungen beziehen, sind vorgesehen.

• Lese die Seite N, die Daten D werden zurückgegeben
• Schreibe die Daten D zur Speicherstelle X, die umgeleitete Speicherstelle Y wird zurückgegeben
• Fordere eine halbtemporäre Speicherstelle an, die Speicherstelle SX wird zurückgegeben
• Schreibe die halbtemporären Daten D zur Speicherstelle SX
• Gebe die halbtemporäre Speicherstelle SX (oder alle) frei
• Tausche (oder verschiebe) den Inhalt der Speicherstellen X und Y
• Lese die Header-Seite, die Daten D werden zurückgegeben
• Die halbtemporäre Speicherstelle SX zum Herunterfahren der Platte ist Root

Der Enforcer validiert die vom OSfilter ausgeführten Austauschanforderungen, da der Enforcer Kenntnis über die anwendbaren Datenstrukturen hat. Obwohl der OSFilter die durch den Enforcer erzeugten Datenstrukturen lesen und referenzieren kann, kann der OSfilter folglich nie Änderungen oder Anfrageaktionen ausführen, die die Datenstrukturen des Enforcer ungültig machen würden, da ihm nicht vertraut wird. Mit anderen Worten, der Enforcer führt die Teile der Engine aus, die sicherstellen, daß für das OS sichtbare, überschriebene Daten zu historischen Daten gemacht werden. Die historischen Daten sind veraltet und werden ordnungsgemäß wiederaufbereitet. Jede Neuorganisation der Platte (zur Optimierung) wird ohne die Möglichkeit einer Verfälschung ihrer eigenen Datenstrukturen ausgeführt. Der OSfilter führt andererseits den Rest der Engine aus, wie zum Beispiel das Neuabbilden der durch das Betriebssystem gelieferten Speicherstellen der Platte dorthin, wo sie momentan angeordnet sind (wie durch den Enforcer gesteuert).
Eine in einem OSfilter/Enforcer-Modus laufende Platte ist für ein Betriebssystem ohne den OSfilter für ein geeignetes Neuabbilden seiner Zugriffe unbrauchbar. Wenn ein Plattencontroller sich in diesem Modus befindet, wird deshalb empfohlen, daß er die normalen Befehle (z.B. lese oder schreibe eine Seite) nicht akzeptiert. Es ist jedoch vorgesehen, daß die Platte zwischen normalen und OSfilter/Enforcer-Modi umschalten kann. Beim Abschalten des OSfilter/Enforcer-Modus werden alle historischen Daten verworfen und die das Hauptabbild erzeugenden Seiten werden zu ihren nicht abgebildeten Speicherstellen verschoben.
Softwareschutz bei Fehlen von Hardwareschutz
Die OSfilter/Enforcer-Aufteilung ist eine durch Hardware geschützte Ausführung der Engine. Als solche kann sie gegen die Verwendung inkompatibler Software schützen, die versucht, direkt auf die Platte zuzugreifen. Zum Beispiel ändern verschiedene angebotenen Dienstprogramme die Master Boot Record [erster logischer Sektor eines bootfähigen Mediums] (MBR)-Seite. Diese Seite muss zur Sicherstellung des ordnungsgemäßen Ladens der Engine (oder des OSfilter) der Steuerung der Engine unterliegen. Wenn ein Anwender von der Diskette anstatt von der Festplatte hochfährt, wird er ferner die zur Ansicht der Festplatte erforderliche Engine (oder den OSfilter) nicht geladen haben. Mit dem im Plattencontroller ausgeführten Enforcer kann jedoch eine derartige inkompatible Software die Datenstrukturen der Engine nicht beschädigen.
Obwohl zuvor dargelegt wurde, daß die Aktualisierung der Hardware für Millionen von PCs im Vergleich zur Ausgabe einer neuen Software unpraktisch ist, ist es eine weniger schwierige Aufgabe, eine neue Festplatte einzuführen. Da die Kapazität steigt, werden letzten Endes Festplatten auf PCs routinemäßig nachgerüstet. Die Bereitstellung einer Hardware-Lösung in der Festplatte, gekoppelt mit einer neuen Software, die in der Haupt-CPU (Hauptplatine) läuft, ist deshalb vorteilhaft. Man beachte, daß die „Hardware"-Lösung in der Festplatte wahrscheinlich aus einer Modifizierung ihrer Firmware (Software) besteht.
Bei Fehlen irgendeines Hardware-Schutzes maskiert die Engine die Platte zur Vermeidung einer Modifikation der Platte durch inkompatible Software. Sie verschiebt die entscheidenden OS-Datenstrukturen, wie die FAT und Partitionstabellen, zu neuen Speicherstellen und ersetzt sie durch Datenstrukturen, die eine maskierte Platte repräsentieren. Die Maskierung nimmt eine von zwei Formen an: eine unbrauchbare Platte (verfälscht außerhalb jeden Versuchs zur Reparatur oder Modifikation) oder eine vollständig gültige, aber harmlos imitierte Platte. Im letzten Fall stellen die FAT und Partitionstabellen eine sehr kleine, aber richtig strukturierte „imitierte" Platte dar, die in die gesamte Platte eingebettet ist. Da alles an dieser imitierte Platte gültig ist, sollten sich Reparaturdienstprogramme in den Grenzen der imitierten Platte aufhalten. Die Engine kennt jedoch die Lage der wirklichen Daten und Abgren zungen der Platte. Da die Engine keinen, der imitierten Platte zugeordneten Daten vertraut, würden an der imitierten Platte ausgeführte Änderungen nicht die Datenstrukturen der Engine verfälschen.
Vervielfältigung der Daten auf der Platte zur Vermeidung eines Verlustes
Sobald die Engine die Daten im RAM als unverfälscht validiert hat und im Begriff ist zur Platte zu schreiben, werden die Daten auf zwei verschiedene Speicherstellen geschrieben. Wenn die Wiedergewinnung einer Kopie fehlschlägt, ist folglich eine zweite verfügbar. Beide Kopien sollten zu einigermaßen entfernten Speicherstellen geschrieben werden, so daß eine Verfälschung in einem Bereich der Platte nicht den Verlust beider Kopien bewirkt. Der tatsächliche Schreibprozess sollte ferner zur Vermeidung der Übertragung beider Kopien von der Hauptplatine zum Plattencontroller in einer Anforderung in zwei unabhängige Schreibanforderungen getrennt werden. Sobald die Daten auf dem Plattencontroller angekommen sind, werden sie wahrscheinlich in den Cache eines Puffers für anhängige Schreiboperationen aufgenommen und eine kurze Zeit später in einer optimalen Art und Weise (mit Minimierung der Kopfsuche und der Übertragungszeit) tatsächlich auf das Plattenmedium herausgeschrieben.
In einigen Fällen kann es sinnvoll sein, nur eine Kopie der gegebenen Datenstruktur der Engine auf die Platte zu schreiben, solange bekannt ist, daß diese Datenstruktur im Falle eines Plattenfehlers von anderen duplizierten Datenstrukturen wiederhergestellt werden kann. Zum Beispiel kann die Hauptbereichs-Speicherbelegungstabelle aus den historischen Daten erstellt werden.
Die Durchführung einer Flush-Operation des Schreib-Caches ohne einen Flush-Befehl
Unter der Annahme, daß die Engine nicht die Fähigkeit aufweist, die Durchführung einer Flush-Operation des Schreib-Caches zu steuern, wirft der Cache im Falle eines Absturzes ein schwieriges Problem auf. Zum Beispiel wird wahrscheinlich eine Netzunterbrechung bewirken, daß ein Teil des Schreib-Caches nie auf die Platte geschrieben wird. Das Problem der Engine besteht darin, daß einige ihrer Daten auf die Platte geschrieben worden sein können und andere Teile nicht; jedoch kann aufgrund des Schreib-Caches die Reihenfolge, in der die Daten durch die Engine geschrieben wurden, nicht mit der korrelieren, mit der auf die Platte geschrieben wurde. Wenn die Engine zu den Speicherstellen eins, zwei und drei auf der Platte schreibt und dann abstürzt, ist es daher möglich, daß die Speicherstellen eins und drei aktualisiert wurden, nicht aber zwei.
Da es wenige Datenstrukturen gibt, die vollkommen verwendbar sind, wenn Teile fehlen, nutzt die vorliegende Erfindung die zeitliche Alterung als ein Mittel der Sicherstellung der Integrität der auf die Platte geschriebenen Daten. Man wird allgemein annehmen, daß sich ein Schreib-Cache-Algorithmus nicht für eine unbegrenzte Zeitdauer zurückhalten wird, seine Daten auf der Platte festzuschreiben. Man nimmt an, daß dies selbst in Situationen konstanter Lese- und Schreibaktivität zutrifft. wenn dies nicht der Fall wäre, ist es vorstellbar, daß eine am Morgen geschriebene Datei selbst Stunden später noch nicht auf dem Plattenmedium angelangt ist, da die Daten in Erwartung, in einer „optimalen" Zeit geschrieben zu werden, im Schreib-Cache festsitzen. Die vorliegende Erfindung gründet sich auf der Annahme, daß nach dem Vorübergehen einer minimalen Zeitdauer (Wartezeit) eine Seite nach dem Schreiben zum Plattencontroller wirklich auf das Plattenmedium geschrieben wird (und somit im Falle eines Absturzes auf nichtflüchtigem Speicher gespeichert wurde).
Deshalb verwendet die vorliegende Erfindung die zeitliche Alterung der Daten. Wobei den Daten im Zusammenhang mit einer Wiederherstellung (Neustart des Systems) genau dann vertraut wird, wenn die Daten mindestens Wartezeit-Sekunden früher auf den Plattencontroller geschrieben wurden. Eine Art Zeitstempel oder Zeitmarke ist in einen Datenblock eingefügt, der zum Plattencontroller geschrieben wird, wobei ein Block aus mehreren Seiten der Platte besteht. Wenn ein(e) nachfolgende(r) Zeitstempel oder Zeitmarke gefunden wurde, der/die mindestens Wartezeit-Sekunden später geschrieben wurde, wird angenommen, daß der Block tatsächlich im vollen Umfang auf das Plattenmedium übertragen wurde. Ein Zeitstempel ist ein Wert, der direkt dem Ablesen einer Uhr entspricht. Durch den Vergleich zweier Zeitstempel ist es möglich, die Länge des dargestellten Zeitintervalls zu bestimmen. Andererseits kennzeichnet eine Zeitmarke lediglich, daß Wartezeit-Sekunden seit der vorherigen Zeitmarke vergangen sind.
Die Beobachtung der zum Plattencontroller übertragenen Datenmenge kann zur Annäherung einer Wartezeit verwendet werden. Da die Übertragungsrate zum Plattenkontroller bekannt ist, ergibt ihre Multiplikation mit der Wartezeit die Datenmenge, die nach dem Schreiben einer gegebenen Seite übertragen werden muss, um sicherzustellen, daß diese Seite wirklich auf das Plattenmedium geschrieben wurde. Dabei nimmt man die Durchführung kontinuierlicher Übertragungen an.
Die Annahme, daß nach einer geeigneten Wartezeit zuvor geschriebene Daten tatsächlich auf der Platte ankommen, kann für bestimmte Plattencontroller nicht gelten. In einem derartigen Fall wird ein alternatives Verfahren verwendet. Hierbei stellt die Engine sicher, daß es eine ausreichende Menge an „freier Zeit" seit einer gegebenen Schreib-Operation für den Plattencontroller gab, um die Flush-Operation seines Schreib-Caches auf die Platte durchzuführen. Die Engine kann die durchschnittliche Anzahl von Übertragungen zum Plattencontroller überwachen. Dies wird mit der bekannten oder geschätzten maximalen Übertragungsrate (die die Rate widerspiegelt, mit der Daten tatsächlich vom Plattenmedium gelesen oder geschrieben werden können) verglichen, um zu bestimmen, ob es angemessen ist zu erwarten, daß eine Flush-Operation des Schreib-Caches durchgeführt wurde. Wenn eine Flush-Operation erforderlich und eine nicht ausreichende freie Zeitdauer vorübergegangen ist, kann die Engine einfach eine Verzögerung einfügen (oder eine Reihe kurzer Verzögerungen, um eine plötzliche Pause in der Plattenaktivität zu vermeiden). Die ungünstigste Übertragungsrate des Laufwerkes kann aus einem Zeitkalibrierungsprogramm abgeleitet werden, das sehr große Datenblöcke (sehr viel größer als jede angemessene Cache-Größe) liest und schreibt. Man beachte, daß die Berechnungen die Anzahl der Übertragungen, ihre relative Nähe und ihre Größe berücksichtigen müssen, da jedes unabhängig zur Gesamtübertragungsrate beiträgt. Mit anderen Worten, es gibt zusätzlichen Zeitaufwand zu der mit dem Start jeder Übertragung verbundenen physikalischen Verschiebung eines Plattenkopfs und einer bestimmten, mit der tatsächlichen Übertragung der Daten auf das Medium der Platte aufgewendeten Zeitdauer.
Eine Analogie zum Verfahren der freien Zeit der Durchführung einer Flush-Operation eines Caches eines Plattencontrollers besteht darin, sich den Cache als einen Eimer vorzustellen, dem Tassen mit Wasser hinzugefügt werden. Der Eimer weist in seinem Boden ein Loch auf, das seine Entleerung mit einer festen Rate gestattet. Das aus dem Loch fließende Wasser entspricht den vom Plattencontroller auf das Plattenmedium geschriebenen Daten. Der Prozess des Hinzufügens von Tassen mit Wasser entspricht dem Schreiben von Daten zum Plattencontroller. Wenn der Eimer voll ist, muss gewartet werden. Das Lesen von Daten vom Plattencontroller entspricht dem vorüber gehenden Verstopfen des Loches – nichts wird entleert, nichts hinzugefügt, jedoch geht die Zeit einfach vorüber (man nimmt an, daß ein Lese-Cache unabhängig von einem Schreib-Cache ist). Jetzt ist die Situation der Durchführung einer Flush-Operation eines Schreib-Caches sehr ähnlich der Notwendigkeit, von Zeit zu Zeit sicherzustellen, daß eine dem Eimer hinzugefügte, gegebene Tasse mit Wasser entleert wurde. Jedoch kann man nicht tatsächlich in den Eimer sehen oder erkennen, ob sich das Wasser immer noch entleert. Wenn man dem Eimer eine Tasse Wasser hinzufügt, wird sie ferner sowohl mit den vorher als auch mit denen danach hinzugefügten Tassen vermischt.
Der einzige Weg wirklich zu wissen, daß die fragliche Tasse mit Wasser wirklich geleert wurde, ist sicherzustellen, daß sich der Eimer zu einem Zeitpunkt nach dem Hinzufügen der Tasse für einen Augenblick vollständig entleert hat. Die Bestimmung wann oder wie dieses Ereignis zu erzeugen ist, ist die Herausforderung, da man nicht in den Eimer sehen oder wissen kann, ob er sich immer noch entleert. Mit anderen Worten, es gibt keine Standardschnittstelle, einen Plattencontroller zu fragen, ob eine Flush-Operation an seinem Cache durchgeführt wurde. Die Lösung besteht darin, die schlechteste Rate zu bestimmen, mit der sich das Wasser aus dem Eimer entleert. Dies erfolgt mit einem Test, bei dem man so schnell wie möglich Tassen mit Wasser hinzufügt, bis man gezwungen ist zu warten, da der Eimer voll geworden ist. Nach diesem Zeitpunkt setzt man fort, Tassen hinzuzufügen, während sich der Eimer entleert (und eine weitere Tasse annehmen wird) und man misst die Rate. Dieser Prozess hat den „Puffer"-Effekt des Eimers in wirksamer Weise bezwungen. Man misst jetzt die tatsächliche Entleerungsrate (oder Rate, mit der der Plattencontroller seinen Cache entleeren kann).
Mit Kenntnis der Rate, mit der sich der Eimer entleert, kann man die Rate überwachen, mit der man Tassen mit Wasser hinzufügt. Wenn man eine Tasse hinzufügt, von der man sicherzustellen wünscht, daß sie entleert wurde, muss man die Rate zukünftiger Zugaben herabsetzen, so daß sich der Eimer schneller entleert, als man neue Tassen hinzufügt. Zu einem berechenbaren Zeitpunkt wird der Eimer vollständig entleert sein, ungeachtet der Tatsache, daß man weiter Tassen hinzufügt, sei es auch langsam. Wenn man natürlich relativ schnell sicherstellen muss, daß der Eimer entleert wurde, bevor man noch eine weitere Tasse hinzufügt, kann man lediglich die berechnete Zeit abwarten, die für die Entleerung des Eimers erforderlich ist. In der Tat kann man durch eine kontinuierliche Überwachung der Zugaberate zum Eimer sogar ein Gefühl dafür haben, wie voll der Eimer zur Zeit der Zugabe der Tasse war, die entleert werden muss. Dies gestattet eine Reduzierung der Verzögerung. Natürlich muss in dieser Näherungsumgebung ein großer nutzloser Zuschlag hinzugefügt werden (wenn man z.B. denkt, daß die vollständige Entleerung eine Sekunde dauert, wartet man zwei Sekunden, um jeden kleinen Fehler in den Berechnungen abzudecken).
Diese Wassereimeranalogie stellt das Verfahren der freien Zeit zur Durchführung einer Flush-Operation eines Schreib-Caches dar. Man beachte, daß die Entleerungsrate des Eimers gleich der ist, wie schnell eine Flush-Operation am Schreib-Cache durchgeführt wird. Sie ist eine Funktion der Suchzeit und der Übertragungsraten. Deshalb beeinflusst die Nähe der Daten im Schreib-Cache auf der Platte – die Speicherstellen, zu denen alles auf die Platte geschrieben werden soll – außerordentlich die zur Durchführung einer Flush-Operation am Cache erforderliche Zeit. Mit anderen Worten, eine Datenmenge zu einem Bereich auf dem Plattenmedium zu schreiben, erfordert weit weniger Zeit, als das Schreiben kleiner Bits von Daten über das gesamte Medium hinweg. Es ist jedoch der letztere Fall, der als die schlechteste Rate einer Flush-Operation zeitlich festgelegt und verwendet werden kann, wobei anerkannt wird, daß die tatsächliche Rate im Allgemeinen viel besser sein wird. Da man nicht einschätzen kann, welche Daten aus dem Cache zuerst vom Plattencontroller geschrieben werden, ist es nicht möglich, die zum Plattencontroller geschriebene Speicherstellen der Seite zu überwachen und das Verhältnis der Suchzeit zur Übertragungszeit zu schätzen und dabei eine geschätzte momentane Rate der Flush-Operation dynamisch zu erzeugen.
Es wird zum Sachverhalt des Plattencontrollers zurückgekehrt. Die nächste Frage besteht allgemein darin, wann zur Sicherstellung einer Flush-Operation des Schreib-Cache eine Verzögerung einzufügen wäre. Es gibt den Prozess der Umleitung von Schreib-Operationen. Im Allgemeinen kann der Anwender für einen Zugriff nur Zeitpunkte auswählen, zu denen es eine Pause in der Plattenaktivität gibt (sicherer Zeitpunkt). Dies vermeidet den Zugriff auf Daten der Vergangenheit, die sich im Prozess der Modifikation befanden. Solange die Pause ausreichend lang ist, ist folglich die Durchführung der Flush-Operation des Schreib-Caches für die Identifikation sicherer Zeitpunkte inhärent. Beim Neustart eines Computers nach einem Absturz hat der Anwender die Option, auf einen vorherigen Zeitpunkt zurückzugreifen, der ein sicherer Zeitpunkt sein wird, oder die Platte lediglich im Zustand unmittelbar vor dem Absturz zu verwenden. Im letzteren Fall stellt die Engine ihre Datenstrukturen für einen Zeitpunkt wieder her, zu dem es möglicherweise keine Pause in der Plattenaktivität gegeben hat. Mit anderen Worten, der Absturz trat in der Mitte einer langen Folge von Plattenaktivitäten auf. Wenn das auf der Wartezeit basierende Verfahren zur Durchführung der Flush-Operation verwendet wird, werden alle bis zu den Wartezeit-Sekunden vor dem Absturz geschriebenen Daten vorhanden sein. Wenn jedoch dem Plattencontroller nicht vertraut werden kann, daß er nach den Wartezeit-Sekunden tatsächlich Daten auf das Plattenmedium schreibt, hat die Engine keine Rückgriffsmöglichkeit, außer alle vor der letzten aufgezeichneten Zeitmarke der Flush-Operation in der Plattenaktivität geschriebenen Daten zu verwerfen. Mit anderen Worten, wenn die Engine bestimmt, daß eine ausreichende Dauer freier Zeit zur Sicherstellung einer tatsächlich durchgeführten Übertragung eines Datenblock auf das Plattenmedium vergangen ist, schreibt die Engine eine geeignete Zeitmarke heraus. Sobald diese Marke auf dem Plattenmedium angekommen ist, ist die Gültigkeit des Blocks festgelegt. Bei einer Wiederherstellung nach einem Absturz werden auf das Medium geschriebene Daten, für die jedoch keine nachfolgende Zeitmarke gefunden wurde, verworfen, da Teile der Daten fehlen könnten. In der Praxis ist der Anwender im Allgemeinen nicht an Daten interessiert, die sich zum Zeitpunkt des Absturzes gerade in Bearbeitung befanden oder gerade geschrieben wurden. Somit ist das Verwerfen dieser Daten kein Problem.
Eine weitere Art der Aktivität der Engine, die die Durchführung einer Flush-Operation erfordert, ist die Umordnung (Austausch) des Inhaltes der Platte. Dieser Vorgang ist mit eindeutigen Übertragungsschritten verbunden, von denen angenommen wird, daß mit ihnen zu bestimmten Zeitpunkten eine Flush-Operation zur Platte durchgeführt wird, um den Prozess absturzsicher zu machen (der Prozess kann im Falle eines Absturzes ohne Verlust von Daten wieder aufgenommen werden). Es ist möglich, daß es sehr viele Daten zu verschieben und folglich viele Zeitpunkte gibt, zu denen eine Flush-Operation durchgeführt werden muss. Folglich können während dieser Aktivität Verzögerungen zu bestimmten Zeitpunkten erforderlich sein, um sicherzustellen, daß es Schreib-Operationen tatsächlich zur Platte geschafft haben.
Ein einfaches Beispiel eines angemessenen wirksamen Austauschvorgangs würde die Verwendung eines fünfzig Megabyte großen Austauschbereiches erfordern. Bei einer durchschnittlichen Übertragungsrate von einem Megabyte pro Sekunde würde es fünfzig Sekunden dauern, alle Daten zu schreiben. Wenn der Plattencontroller einen ein Megabyte großen Schreib-Cache aufweisen würde, würde der Cache eine Sekunde freier Zeit für die Durchführung einer Flush-Operation auf die Platte benötigen. Es wird deshalb zu einem Zeitpunkt nach dem Schreiben der Fünfzig-Megabyte großen Austauschregion eine (kumulative) Verzögerung von einer Sekunde in den Plattenübertragungen zum Plattencontroller eingefügt, um die Durchführung einer Flush-Operation am ein Megabyte großen Cache sicherzustellen (bei einem Megabyte pro Sekunde). Das Verhältnis von fünfzig Sekunden Schreiben der Austauschregion zu einer Sekunde Verzögerung ist angemessen (eine Beeinträchtigung des Leistungsverhaltens um zwei Prozent).
Man beachte, daß ein wichtiger Aspekt zur angemessenen Gestaltung dieses Verhältnis darin besteht, daß die Menge von Daten, die zwischen den Zeitpunkten geschrieben wurden, zu denen es bekannt sein muss, daß mit ihnen eine Flush-Operation zur Platte durchgeführt wurde, groß sein kann (im letzten Beispiel wurden fünfzig Megabyte verwendet). Wenn andererseits vor der erforderlichen Durchführung einer Flush-Operation nur ein Megabyte geschrieben werden musste, ergibt sich ein viel weniger erwünschtes Verhältnis zwischen der mit dem Übertragen der Daten verbrachten Zeit und den eingefügten Verzögerungen (eine Sekunde Schreib-Operationen, gefolgt von einer Sekunde Verzögerung oder eine Beeinträchtigung des Leistungsverhaltens um 50%). Bei jeder tatsächlichen Ausführung muss die Engine die Verzögerungszeiten großzügig mit einem nutzlosen Zuschlag versehen, da die genaue Zeitsteuerung eines Plattencontrollers schwer in Erfahrung zu bringen ist. Wie gerade beschrieben wurde, diktiert die Notwendigkeit, große, zwischen (wirksamen) Flush-Operationen geschriebene Bereiche aufzuweisen, eine Engine-Gestaltung, bei der eine gegebene Speicherstelle auf der Platte keine Modifikation erfordert, gefolgt von einer Flush-Operation, gefolgt von einer Modifikation mit einer Rate, die schneller als das Schreiben der großen Bereiche zwischen den Flush-Operationen ist. Später mehr dazu. Trotzdem beachte man, daß der in US '733 beschriebene Austauschprozess die häufige Durchführung von Flush-Operationen zur Folge hat, deren Notwendigkeit jetzt durch die vorliegende Erfindung überwunden wurde.
Das Austauschen wird im Allgemeinen im Hintergrund ausgeführt und kann durch vom Anwender angeforderte Plattenaktivitäten unterbrochen weden. Wenn während des Austauschvorganges eine auf freier Zeit basierende Flush-Operation erforderlich ist und der Anwender eine plötzliche Anhäufung (Burst) von Plattenaktivität startet, wird die erforderliche Verzögerung einfach nach Abschluss der Aktivität des Anwenders eingefügt.
Andere Zeitpunkte, zu denen am Schreib-Cache eine Flush-Operation durchgeführt werden muss, liegen vor, wenn der Vorgeschichtepuffer rasch überschrieben wird und der Umleitungsprozess ausgesetzt ist und wenn das System heruntergefahren wird. Keines dieser Ereignisse tritt mit irgendeiner Häufigkeit auf und folglich ist das Hinzufügen einer gewissen Verzögerung ohne Folge.
Das tatsächliche Verfahren der Kennzeichnung eines gültigen Blocks auf der Platte ist das Herausschreiben eines abschließenden Flags, wie zum Beispiel eines Zeitstempels oder einer Zeitmarke, nachdem eine ausreichende Wartezeit oder eine Zeitdauer ohne Plattenaktivität vergangen ist.
Konstante Plattenaktivität und sichere Zeitpunkte
Das Konzept eines sicheren Zeitpunktes besteht aus einem Zeitpunkt, zu dem alles vorhanden ist (und tatsächlich auf das Medium geschrieben ist), was angemessen auf die Platte gehört. Das bedeutet, daß jede plattenbasierende Operation, wie zum Beispiel das Speichern einer Datei, abgeschlossen ist und alle unterstützenden Strukturen des Betriebssystems aktualisiert wurden. Zu einem derartigen Zeitpunkt könnte das System plötzlich angehalten werden (Reset oder Stromabschaltung) und der Anwender würde erwarten, seine Daten nach dem Neustart des Computers intakt vorzufinden. Im Allgemeinen verwendet die Engine eine Pause in der Plattenaktivität, um einen derartigen Zeitpunkt zu markieren. (Natürlich würde auch ein Signal vom Betriebsystem zur Engine genügen.) In einer Situation, in der ein Computer inmitten einer erheblichen Plattenaktivität zurückgesetzt wird, kann man sich nicht auf das verlassen, was tatsächlich auf das Plattenmedium geschrieben wurde. Deshalb versteht ein Anwender üblicherweise, daß „alles möglich ist". Es gibt jedoch eine weitere Situation. Sie tritt auf, wenn es einen relativ konstanten, aber geringfügigen Umfang von Plattenaktivität gibt. Dergleichen tritt zum Beispiel auf, wenn eine große Datei unter Verwendung eines Modems mit niedriger Geschwindigkeit herunter geladen wird. Des Weiteren kann im Allgemeinen diese Aktivität zur gleichen Zeit mit einer anderen Aktivität auftreten, wie das Speichern eines Textverarbeitungsdokuments (d.h. ein Anwender kann zur gleichen Zeit herunterladen und editieren).
Im Zusammenhang mit einer geringfügigen, aber lang andauernden Plattenaktivität wird die Verwendung einer einfachen Pause (in der Plattenaktivität) zur Errichtung sicherer Zeitpunkte zur Errichtung jeglicher versagen. Dies ist nicht so sehr für die langsam geschriebenen Daten ein ernstes Problem, sondern für alle in keinem Zusammenhang stehenden und unabhängigen Aktualisierungen, die vermischt werden. Mit anderen Worten, man betrachte den Fall eines vier Stunden dauernden Herunterladens. Während der gesamten Zeit editiert ein Anwender eine bestimmte, wiederholt gespeicherte Datei. Wenn sein Computer abstürzt, ist es wichtig, sichere Zeitpunkte bereitzu stellen, so daß sowohl ein großer Teil des Heruntergeladenen als auch die verschiedenen Versionen der bestimmten Datei wiederherstellbar sind.
Die vorliegende Erfindung setzt deshalb ein technisch ausgereifteres Mittel zur Erfassung, wann sichere Zeitpunkte eingefügt werden sollten, ein. Anstelle der Suche nach einer vollständigen Pause in der Plattenaktivität für eine gewisse Mindestdauer überwacht die Engine die Plattenaktivitätsrate. Immer wenn es einen plötzlichen Abfall in der Aktivität gibt, wird ein sicherer Zeitpunkt eingefügt. So lange sich die Plattenaktivität unter einer, ein maximales Niveau widerspiegelnde Rate befindet (d.h. es ist eine solche Rate, bei der das Betriebssystem wahrscheinlich häufiger eine Flush-Operation seines Caches durchführt), können mit einer angemessenen Rate sichere Zeitpunkte automatisch eingefügt (erzwungen) werden. Eine Darstellung der Platte für einen erzwungenen sicheren Zeitpunkt wird wahrscheinlich viele der bis zur ausgewählten Zeit geschriebenen Daten ergeben. Jedoch können einige Dateiaktualisierungen mitten drin erwischt worden sein.
Erzwungene sichere Zeitpunkte können außerdem nach der Beobachtung eines plötzlichen Abfalls in der Rate von durch das Betriebssystem verarbeiteten Operationen des Öffnens und Schließens von Dateien erzeugt werden. In jedem Fall sollten erzwungene sichere Zeitpunkte periodisch nach jeder Schreibaktivität zur Platte in einem minimalen Zeitintervall eingefügt werden, um eine ständige Verfügbarkeit von Positionen, auf die zurückgegriffen werden kann (sichere Zeitpunkte), sicherzustellen.
Geteilte Platten
Die vorhergehende Erörterung sicherer Zeitpunkte erfolgte unter der Annahme eines Computersystems für einen einzelnen Anwender, in dem die Engine die Aktivität des Anwenders aus der Plattenaktivität ableiten kann. Wenn es zum Beispiel eine plötzliche Anhäufung von Schreibaktivitäten auf die Platte gibt, wird der Anwender wahrscheinlich eine Datei speichern. Wenn man zur Zeit vor der plötzlichen Anhäufung geht und sich die Platte betrachtet, sieht man die Datei vor ihrer Aktualisierung und nach der plötzliche Anhäufung sieht man die Datei mit ihren Änderungen. In einer Umgebung mit einer geteilten Platte (z.B. einem Netzwerk-Dateiserver) werden jedoch die Aktivitäten von zwei oder mehr Anwendern in der Gesamt-Plattenaktivität miteinander vermischt. Es gibt keine Möglichkeit, systemweite sichere Zeitpunkte zu kennzeichnen, da eine Pause in der Plattenaktivität eines Anwenders inmitten der Aktivität eines anderen Anwenders auftreten kann. Um mehrere Anwender zu unterstützen, muss es folglich irgendein Mittel zur Aussortierung der Aktivität jedes Anwenders und zur Sicherstellung der Durchführung einer Flush-Operation am Ende ihrer Aktivität geben. Des Weiteren ist es nicht wünschenswert, die Wiederherstellungsfähigkeit für alle Anwender durch eine erhebliche Plattennutzung eines Anwenders stark zu reduzieren. Vom Standpunkt des Anwenders aus ist es deshalb wünschenswert, daß jeder Anwender seinen eigenen unabhängigen Vorgeschichtepuffer aufweist.
Ein Hauptunterschied zwischen einem Computersystem für einen einzelnen Anwender und einem System mit geteilter Platte besteht darin, daß das zeitliche Zurücksetzen eines Systems für einen einzelnen Anwender oft eine gute Lösung zum Lösen eines Problems ist, das kürzlich eingebracht wurde, jedoch dessen Beschaffenheit nicht wirklich verstanden wird. Mit anderen Worten, wenn der Computer eines Anwenders jetzt nicht arbeitet, jedoch eine Stunde zuvor arbeitete, ist die einfachste Vorgehensweise, auf eine Stunde zuvor zurückzusetzen und dann alle während dieser verworfenen Stunde modifizierten, gewünschten Dateien wiederherzustellen. Im Zusammenhang mit einer geteilten Platte möchte man jedoch nicht, daß ein Anwen der zur Lösung eines Problems, das nur er wahrnahm, das gesamte System zeitlich zurücksetzt. In einer Umgebung mit einer geteilten Platte arbeitet das System im Allgemeinen ordnungsgemäß und die Anwender haben den Bedarf, bestimmte Dateien oder Verzeichnisse wiederherzustellen. Wenn jedoch ein einzelnes oder von vielen Anwendern geteiltes System verfälscht wird, so daß es nicht mehr funktioniert, ist ein zeitliches Rücksetzen des gesamten Systems eine gute Lösung. In einer geteilten Umgebung wird angenommen, daß das Betriebssystem an seinen, die Organisation der Platte beschreibenden, internen Datenstrukturen periodisch eine Flush-Operation (vom RAM auf die Platte) durchführt, so daß ein Zurücksetzen zu einem zeitlich zurückliegenden Zeitpunkt ein im Wesentlichen verwendbares System ergibt. Unter Windows NT kann zum Beispiel die Engine die Durchführung der Flush-Operation des OS-Caches initiieren (der Cache des Betriebssystems unterscheidet sich vom Cache des Plattencontrollers), um das Auftreten dieses Prozesses mit einer gewünschten Rate sicherzustellen.
Das alle Anwender betreffende Zurücksetzen einer geteilten Platte zu einem Zeitpunkt in der Vergangenheit ist hauptsächlich nützlich, wenn das System sich als Ganzes als funktionsunfähig erwiesen hat. Dies kann zum Beispiel auftreten, wenn bedeutende Verbesserungen oder Aktualisierungen der Software ausgeführt werden.
Abgesehen von einem funktionsunfähig werdenden Betriebssystem ist der Vorgang des Zurücksetzens der gesamten Platte nicht nützlich. Stattdessen könnten die Anwender wünschen, bestimmte Dateien und Verzeichnisse zurückzusetzen (wiederherzustellen). Dies führt zu einem Bedarf, die Aktivitäten der Anwender zu trennen und die Durchführung einer Flush-Operation an ihren Daten aus dem OS-Cache sicherzustellen. Mit anderen Worten, man nehme das Beispiel eines Anwenders, der eine Datei modifiziert und die Änderungen in den OS-Cache gehen. Ein anderer Anwender führt danach viele Datei-E/A aus, so daß keine Flush-Operation des OS-Cache durchgeführt wird. Danach modifiziert der ursprüngliche Anwender die Datei erneut. Diese gesamte Aktivität wird niemals auf die Platte geschrieben worden sein. Deshalb gibt es keine Möglichkeit, beispielsweise die erste Version der modifizierten Datei basierend auf dem auf die Platte Geschriebenen wiederherzustellen.
Die Lösung für die Engine besteht darin, die Aktivität der Anwender zu überwachen, einen Anwender vom anderen zu trennen und wenn es vorkommt, daß ein gegebener Anwender eine Reihe von Dateiänderungen beendet hat, die Durchführung der Flush-Operation vom OS-Cache für diese Änderungen zu erzwingen. Es kann sich als schwierig erweisen, die Zuordnung der Daten im OS-Cache zu den Anwendern auszusondern, insbesondere unter Beachtung, daß einige Daten von mehr als einem Anwender modifiziert worden sein könnten. Eine Lösung besteht einfach in der Durchführung einer Flush-Operation des gesamten Cache zu Zeitpunkten, die mit dem Bedarf der Errichtung eines sicheren Zeitpunktes für einen Anwender übereinstimmen, selbst wenn andere Anwender inmitten der Anfertigung von Änderungen sind.
Die nächste Frage ist, wie man die Dateiaktivität eines Anwenders von derjenigen eines anderen isoliert. Wenn sich die Engine in das Betriebssystem auf einer Ebene einhakt, so daß sie jede Dateianforderung und den veranlassenden Anwender sieht, kann sie leicht unabhängig für jeden Anwender nach Pausen in der Aktivität suchen. Wenn eine Pause erkannt wird, kann eine Flush-Operation des gesamten OS-Caches durchgeführt und ein sicherer Zeitpunkt für den speziellen Anwender errichtet werden.
Wenn es keine Möglichkeit gibt, sich in das Betriebssystem auf einer Ebene zur Zuordnung der einzelnen Anwender zu den Dateianforderungen einzuhaken, ist das nächstbeste Verfahren die Beobachtung der Häufigkeit des Zugriffs auf Dateien und Verzeichnisse. Man kann nach einer Pause im Zugriff auf nicht geteilte Verzeichnisse suchen. Man kann auch eine Liste der modifizierten Dateien führen. Wenn seit der letzten Modifikation der Datei eine minimale Zeit abgelaufen ist und nun eine weitere Anforderung zur Modifikation der Datei auftritt, könnte eine Flush-Operation des OS-Cache durchgeführt und ein sicherer Zeitpunkt errichtet werden, bevor die neue Anforderung verarbeitet wird. Dies würde sicherstellen, daß der vorherige Zustand der Datei erforderlichenfalls wiederhergestellt werden könnte. Dieser erzwungene sichere Zeitpunkt würde natürlich nur bei einer Überschneidung der Aktivität mehrerer Anwender erzeugt werden. Wenn die Aktivität eines Anwenders als plötzliche Anhäufung ohne eine Überscheidung mit der Aktivität eines anderen Anwenders auftritt, tritt die Durchführung der Flush-Operation und die Erzeugung eines sicheren Zeitpunktes natürlich in der Pause auf, die der plötzlichen Anhäufung von Aktivität des Anwenders folgt (d.h. dies ist das Szenario für einen einzelnen Anwenders). Wenn so viele Dateien modifiziert werden, daß die Engine nicht alle verfolgen kann, kann sie einfach die Durchführung einer Flush-Operation und einen sicheren Zeitpunkt erzwingen und mit ihrer Verfolgung noch einmal von vorn beginnen. Mit anderen Worten, es schadet außer dem Leistungsverhalten nie, mehr sichere Zeitpunkte als erforderlich zu haben. Andererseits ist es wichtig, einen sicheren Zeitpunkt nicht zu verpassen, da dies impliziert, daß der Anwender nicht zum entsprechenden Zeitpunkt zurückkehren kann.
Die Trennung der Aktivität der Anwender unter Verwendung des Verfahrens der Erzwingung sicherer Zeitpunkte erfolgt bei einer zweiten Modifikation einer bestimmten Datei und nach dem Ablauf einer minimalen Zeit seit der ersten Modifikation indirekt. Die Engine stellt einfach sicher, daß sichere Zeitpunkte zur angemessenen Aussonderung der verschiedenen Versionen von Dateien existieren, was die Trennung der Aktivität der Anwen der impliziert. Es wird für einen einzelnen Anwender mehr sichere Zeitpunkte als erforderlich geben. Aber jeder Anwender wird aus der Gesamtmenge verfügbarer sicherer Zeitpunkte die seiner eigenen Aktivität zugeordneten aussuchen.
Ein einfaches, rekonstruierbares Abbildungssystem Es wird zum Sachverhalt der Verfälschung der Datenstrukturen der Engine zurückgekehrt. US '733 beschrieb (schrieb jedoch nicht vor) die Verwendung komplexer Datenstrukturen, für die der Verlust einiger Daten zum Verlust aller Daten führen kann. Wenn zum Beispiel eine Baum-Datenstruktur zur Neuabbildung der Platte verwendet wird und ein Teil des Baumes (ein Knoten) verloren geht; kann der gesamte Baum unbrauchbar gemacht werden. Da der Baum die tatsächliche Anordnung der Daten des Anwenders auf der Platte beschreibt, sind effektiv ohne den Baum die Daten des Anwenders verloren (oder genauer gesagt durcheinander).
US '733 beschrieb die Verwendung von Vorgeschichte-Headern und einer Speicherbelegungstabelle des Hauptbereichs. Obwohl das Temp-Verfahren in US '733, wenn es die Zeit erlaubte, historische Daten und Hauptbereichsdaten zu ihren entsprechenden Speicherstellen austauschte, war es möglich, daß nicht ausgetauschte historische Seiten wieder verwendet wurden. Sie konnten neue Hauptbereichsdaten oder interne Speicherbelegungstabellen der Engine enthalten oder grundsätzlich die meisten Arten der von der Engine verwalteten Daten. Man betrachte den Fall einer Platte mit einer Speicherstelle, angenommen 10, die die Daten AA enthält, die der für das OS sichtbaren Speicherstelle 10 entsprechen (es ist kein Abbilden erforderlich). Jetzt überschreibt der Anwender diese Daten mit BB und die Engine leitet die Daten von der Speicherstelle 10 zu 50 um. Die Speicherstelle 10 enthält jetzt die historischen Daten AA. Mit der Zeit werden die historischen Daten AA sehr alt, da mehr Daten modifiziert und neue historische Zustände bewahrt werden. Schließlich wird die Speicherstelle 10 zu den ältesten historischen Daten und deshalb die nächste Speicherstelle zur Wiederverwendung, für welchen Zweck auch immer sie von der Engine benötigt wird, wie zum Beispiel als Knoten in einer Speicherbelegungstabelle oder um eine umgeleitete Schreib-Operation zu empfangen. Die Bedeutung dieses Szenarios besteht in der Darstellung, wie das beschriebene Temp-Verfahren zur Speicherung aller Arten von Datentypen über das Medium einer Platte hinweg führt (d.h. vermischt mit den momentanen Abbildungsdaten des Anwenders).
Wir stellen jetzt das Problem einer durch eine unbekannte Quelle verursachten, nicht korrigierbaren Verfälschung vor. Die vorher beschriebenen Techniken des Duplizierens von Daten auf der Platte und im RAM und der sorgfältigen Validierung zur Erkennung einer Verfälschung im RAM vor der Verbreitung auf die Platte werden die Wahrscheinlichkeit einer Verfälschung wesentlich reduzieren, aber sie kann trotzdem auftreten. Wenn die Datenstrukturen mit Verknüpfungen verbunden sind, wobei zum Beispiel Seite A Daten enthält, die auf B zeigen und B Daten enthält, die auf C zeigen, bedeutet der Verlust der Daten von Seite B, das C ebenfalls verloren ist. Folglich ist die Verfälschung einer komplexen, auf Verknüpfungen basierenden Datenstruktur im Allgemeinen katastrophal.
Andererseits ist eine Datenstruktur, die normalerweise gegen eine teilweise Verfälschung widerstandsfähig ist, eine sequentielle Folge von Seiten. Wenn zum Beispiel die Speicherstellen der Seiten #5, #6, #7 und #8 den ASCII-Text eines Dokuments enthalten und Seite #6 verfälscht wird, kann man immer noch einen Teil des Textes von den Seiten-Speicherstellen #5, #7 und #8 wiedererlangen. Wenn andererseits ein Teil der Daten in Seite #5 die Speicherstelle der nächsten Seite kennzeichnete und diese Seite als verfälscht gefunden wurde, würde es im Allgemeinen keine Möglichkeit geben, den Rest des Dokumentes wiederzuerlangen.
Deshalb passt die vorliegende Erfindung die auf dem Temp-Verfahren basierenden beschriebenen Datenstrukturen und Prozesse an. 1 veranschaulicht den Anfangszustand eines New-Temp-Verfahrens. Hier sieht man einen Satz von Seiten des Hauptbereichs, eine Speicherbelegungstabelle und einen Satz von zusätzlichen Seiten und Verlaufs-Header (rechts die beiden nebeneinander angeordneten Spalten). 2 veranschaulicht das Geschehen nach dem Schreiben der Daten „d2a" zur Speicherstelle 2 durch das Betriebssystem. Die Schreib-Operation wurde auf eine zusätzliche Seite umgeleitet und es erfolgte eine Aufzeichnung im entsprechenden Vorgeschichte-Header, der die Datenzugehörigkeit (Speicherstelle 2) kennzeichnet. Man beachte außerdem, daß die Haupt-Speicherbelegungstabelle aktualisiert wurde, um die wirkliche Anordnung der Speicherstelle #2 des Betriebssystems zu kennzeichnen. In 3 wird ein sicherer Zeitpunkt errichtet. 4 veranschaulicht drei weitere Schreib-Operationen. Man beachte, daß man bei der Modifikation einer Seite, die Teil der momentan gebildeten Gruppe ist, Daten direkt überschreiben und die vorherigen Zustände nicht aufrechterhalten werden können, wie sie von sicheren Zeitpunkten begrenzt werden. In 4 wird zur Speicherstelle #1 doppelt geschrieben, wobei der Endzustand in den Bereichen der zusätzlichen Seite gespeichert wird. Die 5 und 6 zeigen Austauschungen, die beim Vertauschen von umgeleiteten und historischen Daten und einer entsprechenden Aktualisierung der Speicherbelegungstabelle ausgeführt werden. (Die an irgendeinem gegebenen Austauschzyklus beteiligten Seiten müssen nicht den Grenzen sicherer Zeitpunkte entsprechen.) Auf den ersten Blick sind diese Datenstrukturen und Prozesse den im Temp-Verfahren beschriebenen sehr ähnlich. Dieses New-Temp-Verfahren gestattet jedoch nicht der nächsten Schreib-Speicherstelle in den Tabellen der zusätzlichen Seite/Verlaufs-Header in die nicht ausgetauschten Daten vorzurücken. Wenn der Austausch in den 5 und 6 nicht auftreten würde, könnte folglich die Engine den gerade beschriebenen Algorithmus nicht fortsetzen. Es wird gehofft, daß es ausreichend zusätzliche Seiten und entsprechende Verlauf-Header gibt zur Aufnahme jeder plötzlichen Anhäufung an Schreibaktivität mit nachfolgender verfügbaren Zeit zur Durchzuführung eines Austauschs, so daß der Überlaufzustand selten ist. Wenn jedoch ein Überlauf auftritt, bei dem so viele Daten schnell geschrieben (und umgeleitet) werden, so daß keine danach ausgetauschten zusätzlichen Seiten verfügbar sind, fährt die Engine herunter. Dies hat eine Benachrichtigung des Anwenders darüber zur Folge (wenn möglich), daß alle historischen Daten in Begriff sind, verloren zu gehen und danach mit dem Schreiben der Daten zu einer durch die Haupt-Speicherbelegungstabelle zuletzt gekennzeichneten Speicherstelle fortzusetzen. Wenn schließlich eine freie Zeit auftritt, werden Austauschungen durchgeführt und danach die Vorgeschichte-Header zurückgesetzt (neu initialisiert, um zu kennzeichnen, daß keine gesicherten historischen Zustände vorliegen).
Das New-Temp-Verfahren unterscheidet sich vom ursprünglichen (alten) darin, daß es zum Herunterfahren gezwungen werden kann. Das ursprüngliche Verfahren konnte ohne jeglichen Austausch ständig fortfahren, wobei eine Art von Fragmentierung auftritt. Mit der Zeit werden die Schreib-Operationen zu zunehmend fragmentierten Speicherstellen umgeleitet, wenn der Anwender mit dem Schreiben ohne eine freie Zeit zum Austauschen fortsetzt. Die Wirklichkeit dieser Beeinträchtigung des Leistungsverhaltens bestand darin, daß das ursprüngliche Verfahren unter Bevorzugung der Fragmentierungsobergrenze und Ansprechempfindlichkeit auf Kosten der Aufgabe der Verfolgung von historischen Zuständen ebenfalls herunterfahren würde. Das Argument bestand darin, daß bei einer schnellen Änderung vieler Daten durch den Anwender nur sehr neue Änderungen rückgängig gemacht werden können. Dies ist von geringem Nutzen. Deshalb ist es besser, herunterzufahren und schneller auszuführen.
Angesichts dessen, das sowohl die neuen als auch die alte Temp-Verfahren herunterfahren, besteht der Unterschied darin, daß das neue Verfahren früher herunterfährt. Das Nicht-Einhüllen der nächsten Schreib-Speicherstelle in nicht ausgetauschte Daten vereinfacht jedoch die Datenstrukturen. Wenn nun zu einem Zeitpunkt die Haupt-Speicherbelegungstabelle verloren gegangen ist, kann sie leicht aus den Vorgeschichte-Headern rekonstruiert werden. Im alten Temp-Verfahren könnte die Haupt-Speicherbelegungstabelle zu der Kennzeichnung kommen, daß sich zwei Seiten des Hauptbereichs in der gegenseitig gewünschten Speicherstelle befinden und deshalb einen Austausch erfordern.
Aufgrund dieser Bedingung kann man die Haupt-Speicherbelegungstabelle nicht ohne den Verlust entscheidender Austauschinformationen verlieren. Dieser Zustand kann jedoch im neuen Temp-Verfahren nicht auftreten und deshalb ist die Haupt-Speicherbelegungstabelle lediglich ein optimiertes Verfahren zur Bestimmung aus den Vorgeschichte-Headern, wo eine gegebene, für das OS sichtbare Seite wirklich angeordnet ist und daher von den Headern wiederhergestellt werden kann.
Der Wiederherstellungsprozess beim Ereignis des Verlustes der Haupt-Speicherbelegungstabelle hat einfach nur das Auffinden der letzten Position des nächsten Schreib-Zeigers, das Rücksetzen der Haupt-Speicherbelegungstabelle und das periodisches Durchlaufen der Vorgeschichte-Header zur Folge. Wenn jeder Header verarbeitet wird, wird die für das OS sichtbare, zu ihrer entsprechenden zusätzlichen Seite abgebildete Speicherstelle zur Haupt-Speicherbelegungstabelle hinzugefügt. In Abhängigkeit von der Bewegungsrichtung durch die Header werden die Vervielfältigungen entweder durch ein Überschreiben der vorherigen Verknüpfung in der Haupt-Speicherbelegungstabelle genommen oder verworfen. Als ein Beispiel gehe man zu 4 zurück und verwerfe alle Verknüpfungen in der Haupt-Speicherbelegungstabelle. Man starte beim nächsten Schreib-Zeiger und bewege sich aufwärts. Der zuerst angetroffene Verlaufs-Header gibt an, daß die Speicherstelle 2 nach „d2b" abbilden sollte, und der nächste gibt an, daß die Speicherstelle #1 nach „d1b" abbilden sollte. Der letzte Header ist eine Wiederholung der Speicherstelle #2. Da wir uns zeitlich rückwärts durch die Header bewegen, wird das Duplikat ignoriert, da die Haupt-Speicherbelegungstabelle die letzten Schreib-Operationen des Anwenders widerspiegelt. Die Haupt-Speicherbelegungstabelle wurde nun wiederhergestellt. In der Tat veranschaulicht dieses Beispiel, daß die Verlaufs-Header die Rolle einer Haupt-Speicherbelegungstabelle spielen könnten, indem die Speicherbelegungstabelle für jeden für das OS sichtbaren Plattenzugriff durchsucht werden könnte, um nachzusehen, wohin die Referenz wirklich geleitet werden sollte. Das Durchsuchen einer riesigen Tabelle für jeden Plattenzugriff ist jedoch sehr ineffizient und erfordert deshalb die Erstellung eines zweiten, optimierteren Mittels zum Nachschlagen.
Die Haupt-Speicherbelegungstabelle ist wahrscheinlich eine komplex verknüpfte Datenstruktur (wie ein Baum) und wird beim Auffinden einer Verfälschung verworfen und wiederhergestellt. Wenn ein Teil der Vorgeschichte-Header verfälscht wird, sind das Ergebnis entweder verlorene historische Zustände oder der Verlust kürzlich geschriebener neuer Daten (die noch nicht mit ihren überschriebenen Historischen Daten vertauscht wurden.) Unter der Annahme, daß der Umfang der Verfälschung begrenzt ist, ist es in jedem Fall sehr wahrscheinlich, daß die meisten Daten des Anwenders intakt und verwendbar sind und die meisten historischen Zustände immer noch verwendbar sind. Im Fall des Verlustes nicht ausgetauschter Seiten kann der Anwender über das Auftreten einer Verfälschung informiert werden. Er/sie sollte alle gewünschten Dateien validieren und eine Sicherungskopie erstellen oder wiederherstellen. Der Zustand der Verfälschung kennzeichnet ernsthafte Probleme des Computers des Anwenders.
Die sequentielle oder tabellenartige Beschaffenheit der zusätzlichen Seiten und Vorgeschichte-Header ermöglicht eine umfangreiche Wiederherstellung und beseitigt nahezu die Wahrscheinlichkeit eines katastrophalen Datenverlustes auf Grund des Verlustes von Schlüsselteilen einer komplexen Speicherbelegungstabelle.
Die sequentielle Beschaffenheit der Art der Aktualisierung von Vorgeschichte-Headern und zusätzlichen Seiten beim Schreiben von Daten durch den Anwender passt leicht in das vorher beschriebene Verfahren der zeitlichen Alterung von Daten zur Sicherstellung einer durchgeführten Flush-Operation von jedem Schreib-Cache. Mit anderen Worten, wenn der Anwender Änderungen vornimmt, werden die Daten dem Nächstes-Schreiben-Zeiger folgend und diesen vorrückend in die Verlaufs-Header und entsprechenden zusätzlichen Seiten geschrieben. Es ist einfach, Merkmale der zeitlichen Alterung zur Kennzeichnung irgendwelcher Bereiche einzuschließen, die sich zum Zeitpunkt eines Absturzes im Prozess der Durchführung einer Flush-Operation aus dem Schreib-Cache befanden.
Der andere bedeutender Prozess der Engine, die Neuorganisation oder der Austausch von Daten auf der Platte, kann ebenfalls leicht zur Unterstützung der Durchführung einer zeitlich gealterten Flush-Operation ausgeführt werden. Anstelle der Bereitstellung eines einzelnen Austauschbereiches und der Verwendung einer Vermittlungs-Seite zur Steuerung von Übergangszuständen wird eine Tabelle von Austauschbereichen errichtet.
Auf diese Art und Weise kann eine Reihe von Austauschzyklen initiiert werden. Während die Daten für eine Phase eines bevorstehenden Austauschzyklus zeitlich gealtert (an ihnen eine Flush-Operation durchgeführt und sie auf der Platte stabilisiert) werden, kann die Einrichtung für eine weitere momentane Phase eines Austauschzyklus durchgeführt werden. Wenn Verzögerungen zur Durchführung von Flush-Operationen eingefügt werden müssen, gestattet zumindest die Verwendung von mehreren Austauschbereichen das Verhältnis der Flush-Operationen zur Plattenaktivität optimal zu halten (weniger Flush-Operationen). Die Austauschphasen haben das Sammeln aller an einem Austausch beteiligten Daten in einem Austauschbereich zur Folge. Sobald diese Sicherungskopie auf der Platte sicher ist (und eine Flush-Operation durchgeführt wurde), können die Daten ohne die Gefahr eines Verlustes im Fall eines Absturzes an den Ort verschoben werden. Man entnehme dem Abschnitt über die Durchführung der Flush-Operation des Schreib-Caches weitere Einzelheiten.
Die soeben für das Temp-Verfahren zur Behandlung der Wiederherstellbarkeit umrissenen Prinzipien können genauso gut auf das Always-Verfahren angewendet werden.

Claims

Ein System zur Reduzierung von Datenverfälschung, aufweisend: ein Protokoll von Änderungen an Daten auf einem Aufzeichnungsmedium; einen Controller mit einer Logik, die Schreiboperationen mit neuen Daten auf dem Aufzeichnungsmedium unter Verwendung des Änderungsprotokolls ausführt, eine vorgegebene Zeitdauer wartet, eine Zeitmarke auf das Aufzeichnungsmedium schreibt und die neuen Daten beim Schreiben der Zeitmarke auf dem Aufzeichnungsmedium bestätigt; und einen Prozessor mit einer Logik, die Leseoperationen von dem Aufzeichnungsmedium unter Verwendung des Änderungsprotokolls ausführt.
Ein System nach Anspruch 1, wobei der Prozessor ferner eine Logik aufweist, die eine Schreibanforderung ausführt, wobei die Schreibanforderung an den Controller übermittelt wird.
Ein System nach Anspruch 1, wobei die Logik des Controllers für auf das Aufzeichnungsmedium geschriebene neue Daten alternative Speicherorte zuweist.
Ein System nach Anspruch 3, wobei die Logik des Controllers die alternativen Speicherorte für die neuen Daten an die Logik des Prozessors übermittelt.
Ein System nach Anspruch 4, wobei die Logik des Prozessors ein Verzeichnis der alternativen Speicherorte für die neuen Daten verwaltet.
Ein System nach Anspruch 5, wobei das Verzeichnis der alternativen Positionen für die neuen Daten, das von der Logik des Prozessors verwaltet wird, unter Verwendung der von dem Controller bereitgestellten Daten wieder aufgebaut werden kann.
Ein System nach Anspruch 1, wobei das Änderungsprotokoll historische Daten betreffende Informationen und sichere Punkte betreffende Informationen enthält.
Ein Verfahren zum Reduzieren von Datenverfälschung, wobei eine zur Ausführung von Schreiboperationen ausgelegte Logik eines Controllers und eine zur Ausführung von Leseoperationen ausgelegte Logik eines Prozessors verwendet wird, wobei das Verfahren die Operationen aufweist: Verwalten eines Protokolls von Änderungen an Daten auf einem Aufzeichnungsmedium; Schreiben neuer Daten auf das Aufzeichnungsmedium; Warten für eine vorgegebene Zeitdauer; Schreiben einer Zeitmarke auf das Aufzeichnungsmedium; Bestätigen der neuen Daten beim Schreiben der Zeitmarke auf das Aufzeichnungsmedium; und Lesen von dem Aufzeichnungsmedium unter Verwendung des Änderungsprotokolls.
Ein Verfahren nach Anspruch 8, wobei den neuen Daten von einer Fehler-Wiederherstellungs-Engine ohne die Zeitmarke nicht vertraut wird.
Ein Verfahren nach Anspruch 8, ferner mit der Operation des Wiederherstellens nach einem Computerausfall unter Verwendung des Protokolls der Änderungen an den Daten auf dem Aufzeichnungsmedium.
Ein Verfahren nach Anspruch 10, wobei während der Wiederherstellung Daten verworfen werden, wenn eine nachfolgende Zeitmarke nicht vorhanden ist.
Ein Verfahren nach Anspruch 8, wobei die vorgegebene Zeitdauer die erforderliche Zeitdauer ist, um sicherzustellen, daß ein Schreib-Cache des Aufzeichnungsmediums einer Flush-Operation unterzogen wurde.
Ein Verfahren nach Anspruch 8, wobei die vorgegebene Zeitdauer länger als die erforderliche Zeitdauer ist, um sicherzustellen, daß ein Schreib-Cache des Aufzeichnungsmediums einer Flush-Operation unterzogen wurde.
Ein Verfahren nach Anspruch 8, wobei das Änderungsprotokoll historische Daten betreffende Informationen enthält.
Ein Verfahren nach Anspruch 14, wobei das Änderungsprotokoll ferner einen Speicherort von mit historischen Daten in Beziehung stehenden aktuellen Daten betreffende Informationen enthält.
Ein Verfahren nach Anspruch 15, wobei das Änderungsprotokoll ferner sichere Punkte betreffende Informationen enthält.
Das Verfahren nach Anspruch 8, ferner umfassend ein Verwalten von mehr als einer Kopie von Daten auf einem Aufzeichnungsmedium, wobei die Kopien von Daten zum Erkennen von Verfälschung vor einem Übertragen zu einem anderen Aufzeichnungsmedium verglichen werden.
Das Verfahren nach Anspruch 8, ferner mit einem Verbergen eines Aufzeichnungsmediums zum Schutz gegen eine das Aufzeichnungsmedium verändernde inkompatible Software.
Das Verfahren nach Anspruch 8, ferner umfassend ein Identifizieren von sicheren Punkten für ein Aufzeichnungsmedium, an denen das Schreiben von kürzlichen Veränderungen der Daten auf das Medium abgeschlossen wurde.
Das Verfahren nach Anspruch 8, wobei eine Mehrzahl von Benutzern Zugriff auf ein Aufzeichnungsmedium hat, wobei das Verfahren aufweist: Aussondern von Benutzeraktivitäten durch Überwachen von Veränderungen an Verzeichnissen und Dateien; und Durchführen einer Flush-Operation eines Schreib-Caches, nachdem die Notwendigkeit zum Erstellen eines sicheren Punktes für einen Benutzer erfaßt wurde.