DE60030872T2

DE60030872T2 - Verfahren und anordnung um atomische aktualisierungen durchzuführen durch verwendung eines logischen flaschspeichergerätes

Info

Publication number: DE60030872T2
Application number: DE60030872T
Authority: DE
Inventors: Jari Matero
Original assignee: Tellabs Oy
Current assignee: Infinera Oy
Priority date: 1999-10-26
Filing date: 2000-10-25
Publication date: 2007-01-18
Anticipated expiration: 2020-10-26
Also published as: AU7929100A; DE60030872D1; EP1224558A1; WO2001031458A1; CN1384937A; ATE340387T1; JP5160006B2; JP2003513357A; FI19992308A; US7254592B1; CN1179281C; FI109620B; EP1224558B1

Description

Die Erfindung bezieht sich allgemein auf die Technik der Handhabung von Aktualisierungen, die aus mehreren Operationen auf einer niedrigeren Ebene bestehen können, welche alle in einer konsistenten Weise erfolgreich sein müssen oder alle fehlschlagen müssen. Speziell bezieht sich die Erfindung auf die Technik der Verwendung einer Speicheradressen-Übersetzungsschicht, wenn Transaktionen durchgeführt werden.
Das Konzept des Durchführens einer Transaktion ist auf dem Gebiet der Aufrechterhaltung von Dateisystemen, auf dem die Integrität der Daten und die Befolgung von bestimmten Geschäftsregeln von grundlegender Bedeutung ist, weit verbreitet. Als ein Beispiel können wir eine Bankgeschäfts-Anwendung betrachten, bei der eine Kontendatei alle Konten mit ihrem aktuell gültigen Kontostand auflistet und eine getrennte Kontenbuchungsdatei alle durchgeführten Kontenbuchungen auflistet. Nehmen wir an, dass ein neuer Datensatz zu der Buchungsdatei erstellt wurde, welcher die Zahlung einer gewissen Geldsumme an oder von einem bestimmten Konto beschreibt. Ein entsprechender Aktualisierungsvorgang bei der Kontendatei wurde jedoch nicht durchgeführt. Das Ergebnis ist eine Verletzung der Datenintegrität in dem Dateisystem: Der Kontostand eines bestimmten Kontos, der von der Kontendatei gelesen wurde, ist nicht der gleiche wie einer, der erhalten wurde durch Durchgehen der Datensätze in der Buchungsdatei. Diese Art von Widerspruch ist gewöhnlich als eine Transaktionskonsistenzverletzung bekannt. Ein anderes Beispiel einer gefährlichen Situation ist eine sogenannte Geschäftsregelverletzung, was bedeutet, dass eine bestimmte applikationsspezifische Regel verletzt ist: beispielsweise wurde ein Eintrag in ein Konto gemacht, dass für die Ansicht und Billigung schon geschlossen ist.
Das Konzept der Transaktion bedeutet, dass alle solche Operationen auf niedrigeren Ebenen, die Veränderungen der Daten in einem Dateisystem verursachen, zusammengruppiert werden, um eine Einheit zu bilden, bei der alle Operationen entweder zusammen erfolgreich sein müssen oder zusammen fehlschlagen müssen. Die Operationen auf niedrigeren Ebenen sind ebenfalls als Aktualisierungsoperationen bekannt. Eine Transaktion wird gewöhnlich in drei aufeinanderfolgende Phasen unterteilt, nämlich das Starten einer Transaktion, das Aktualisieren der Daten und das Abschließen einer Transaktion. Wenn ein schwerwiegender Systemfehler auftritt (z.B. ein Systemreset), dann werden entweder alle Aktualisierungsoperationen durchgeführt oder keine Veränderungen an den Daten gemacht in Abhängigkeit davon, ob die Abschließungsphase erreicht wurde oder nicht. Ein schwerwiegender Systemfehler während einer schon gestarteten Abschließungsphase bewirkt, dass sie unterbrochen wird, jedoch bei der nächsten Inbetriebnahme des Systems beendet wird. Wenn der schwerwiegende Systemfehler auftritt, bevor eine Transaktion ihre Abschließungsphase erreicht hatte, werden alle Spuren dieser Transaktion automatisch während der nächsten Inbetriebnahme gelöscht.
Der Transaktionsmechanismus unterstützt gewöhnlich eine umgekehrte Operation, die als die Zurücksetzungstransaktion bekannt ist, was bedeutet, dass alle Aktualisierungsoperationen, die während der Aktualisierungsphase durchgeführt wurden, abgebrochen werden, statt sie durch Abschließen permanent zu machen.
1 veranschaulicht ein einfaches, konventionelles Dateisystem, welches zum Durchführen von Transaktionen verwendet werden kann. Eine Steuereinheit 101 verwaltet sowohl eine Logdatei 102 als auch eine Datenbankdatei 103. Die Steuereinheit 101 schreibt die Operationen, welche eine Transaktion bilden, zunächst in die Logdatei 102 gemäß dem Pfeil 104. Nachdem alle Operationen erfolgreich in die Logdatei 102 geschrieben wurden, schreibt die Steuereinheit 101 sie neu, d.h. macht die entsprechenden Änderungen, in die Datenbankdatei 103. Diese Operation kann als Transferieren der Veränderungen von der Logdatei 102 zu der Datenbankdatei 103 gemäß dem Pfeil 105 gesehen werden.
Wenn wir die Logdateianordnung von 1 mit einer einfachen Nichttransaktion die auf die Aktualisierung der Daten in der Datenbankdatei 103 gerichtet ist, vergleichen, so bemerken wir, dass die erstere die Menge der Dateischreibvorgänge verdoppelt und einen Dateilesevorgang einführt, der in der letzteren nicht vorhanden ist. Es ist klar, dass solch eine Belastung des Dateisystems schädliche Auswirkungen speziell in groß angelegten Systemen wie Bankapplikationen hat, bei denen die tägliche Anzahl von Transaktionen leicht in der Größenordnung von Hunderttausenden oder Millionen ist.
Eine Druckschrift US 5,832,493 des Standes der Technik ist dafür bekannt, dass sie ein Verfahren der Gestaltung der Lese- und Schreibvorgänge in einer Flash-Speichervorrichtung in solch einer Weise offenbart, dass, sogar wenn ein Systemfehler auftritt, die gültige Version eines Datensektors später durch Verwenden von sektorspezifischen Gültigkeitsindikatoren abgeleitet werden kann.
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren und eine Anordnung zum Durchführen von Transaktionen mit geringerer Belastung eines Dateisystems als bei der Anordnung des Standes der Technik von 1 bereitzustellen. Es ist ebenfalls eine Aufgabe der Erfindung, ein Verfahren und eine Anordnung zum zuverlässigen und wirtschaftlichen Durchführen von Transaktionen bereitzustellen. Eine weitere Aufgabe der Erfindung ist die Bereitstellung solch eines Verfahrens und solch einer Anordnung dergestalt, dass sie auf einfache Weise skalierbar sind zum Berücksichtigen der Anzahl von Transaktionen pro Zeiteinheit.
Die Aufgaben der Erfindung werden gelöst durch Verwenden eines Flash-Speichers oder einer auf ähnliche Weise funktionierenden Vorrichtung als einem Datenspeicher und durch Arbeiten mit dem Nutzlast-Dateninhalt und der Speicheradressinformation des Datenspeichers entsprechend einer bestimmten aufeinanderfolgenden Reihenfolge.
Das Verfahren zum Aktualisieren eines ersten Blockes von digitalen Daten gemäß der Erfindung ist dadurch gekennzeichnet, dass es in der folgenden Reihenfolge die Schritte aufweist:

– Aktivieren eines ersten Bezeichners, der allen jenen Aktualisierungsoperationen gemeinsam ist, die den ersten Datenblock betreffen und entweder alle zusammen erfolgreich sein müssen oder alle zusammen fehlschlagen müssen
– Durchführen all jener Aktualisierungsoperationen, die den ersten Datenblock betreffen und entweder alle zusammen erfolgreich sein müssen oder alle zusammen fehlschlagen müssen
– Speichern des aktualisierten ersten Blockes digitaler Daten in eine logische Flash-Speichervorrichtung zusammen mit einem Wert, der den aktualisierten ersten Datenblock dem ersten Bezeichner zuordnet und
– Deaktivieren des ersten Bezeichners.

Die Erfindung verwendet ebenfalls ein Verfahren zur Wiederherstellung nach einem Systemfehler in einem Dateisystem basierend auf einer logischen Flash-Speichervorrichtung. Es ist dadurch gekennzeichnet, dass es die Schritte aufweist:

– Überprüfen anhand einer Liste von aktiven Bezeichnern, welche Bezeichner zu der Zeit des Auftretens des Systemfehlers aktiv waren, und
– Überprüfen der physikalischen Speicherorte zum Lokalisieren von Datenblöcken, die einen Wert enthalten, welcher sie einem Bezeichner zuordnet, der zu dem Zeitpunkt des Auftretens des Systemfehlers aktiv war und Setzen eines Zustandsindikators jedes solchen nichtflüchtigen Speicherortes, der solch einen Datenblock enthält, auf einen Wert, der anzeigt, dass der Speicherort die ungültigen Daten enthält.

Die Erfindung verwendet ebenfalls eine Anordnung, die dadurch gekennzeichnet ist, dass sie aufweist:

– Eine logische Flash-Speichervorrichtung
– Mittel zum Aktivieren eines ersten Bezeichners, welcher all jenen Aktualisierungsoperationen gemeinsam ist, die sich auf den ersten Datenblock beziehen und entweder alle gemeinsam erfolgreich sein müssen oder gemeinsam fehlschlagen müssen
– Mittel zum Durchführen all jener Aktualisierungsoperationen, die sich auf den ersten Datenblock beziehen und entweder alle zusammen erfolgreich sein müssen oder alle zusammen fehlschlagen müssen
– Mittel zum Speichern des aktualisierten ersten Blockes der digitalen Daten in die logische Flash-Speichervorrichtung zusammen mit einem Wert, der den aktualisierten ersten Datenblock dem ersten Bezeichner zuordnet, und
– Mittel zum Deaktivieren des ersten Bezeichners.

Ein erstes typisches Merkmal von Flash-Speichern ist eine bestimmte frei verfügbare Natur der physikalischen Speicherorte. Ein anderes typisches Merkmal, welches eine Art von Folge des ersten Merkmals ist, ist die Anordnung von solchen Speichern in Blöcken, auf welche unter Verwendung einer bestimmten Menge von Zugriffsregeln getrennt zugegriffen werden kann. Gemäß der vorliegenden Erfindung wird eine Anzahl von Blöcken verwendet zum Speichern von nicht aktualisierten und aktualisierten Versionen bestimmter Nutzlastdaten, deren Inhalte Gegenstand der Aktualisierung durch Transaktionen sind. Adress- und Datenkopfinformationen der Blöcke werden verwendet zum Feststellen, welcher Block die gültigste Version der Nutzlastdaten zu irgendeinem gegebenem Zeitpunkt enthält.
Das Konzept der Flash-Speicher kann so ausgeweitet werden, dass es logische Flash-Speichervorrichtungen oder LFMDs, d.h. beliebige Speichermittel, welche so angeordnet sind, dass sie entsprechend den typischen Merkmalen der Flash-Speicher arbeiten, abdeckt: Organisation von gespeicherten Daten in Blöcken, einmalige Natur des Schreibens in die Blöcke, Statusanzeiger zum Anzeigen des Status der Daten in den Blöcken. Die allgemeine Defi nition von LFMDs deckt ebenfalls hybride Lösungen ab, welche mindestens zwei physikalisch getrennte Speicherorte verwenden zum Speichern eines logisch ganzheitlichen Datenblockes.
Beispielsweise können ein übliches Magnetplattenlaufwerk oder ein statisches RAM (Direktzugriffsspeicher) so eingerichtet sein, dass sie wie ein LFMD arbeiten. Die vollständige Emulation der Flash-Speichereigenschaften ist für ein Magnetplattenlaufwerk gewöhnlich nicht erforderlich: Typischerweise ist das physikalische Löschen von Datenblöcken dabei nicht implementiert. Kombinationen von Magnetplattenlaufwerken und tatsächlichen Festkörper-Flash-Speichern bieten einen vorteilhaften Rahmen für Hybridlösungen: Beispielsweise kann der Datenblockkopf (oder ein Teil von ihm, wie die Statusanzeiger) in dem Flash-Speicher gespeichert sein, während der Rest des Blockes, speziell die Datennutzlast, auf dem Magnetplattenlaufwerk gespeichert ist. Trotz der beiden physikalisch getrennten Orte ist der Datenblock logisch ganzheitlich. Die vorliegende Erfindung ist ebenso anwendbar auf alle LFMDs, unabhängig davon, ob sie physikalisch auf der Flashtechnik basieren oder nicht.
Als ein befähigendes Merkmal der Erfindung ist eine fehlersichere atomare Aktualisierungsprozedur einer kleinsten aktualisierbaren Dateneinheit vorgesehen. Solch eine Dateneinheit weist ein Datenkopffeld mit einem bestimmten Statusanzeiger auf, der eine begrenzte Anzahl von erlaubten Werten hat. Der Statusanzeiger einer aktualisierten Dateneinheit wird verändert zum Anzeigen der Gültigkeit der entsprechenden Nutzlastdaten, wenn die aktualisierten Daten hineingeschrieben wurden. Danach wird der Statusanzeiger der entsprechenden alten Dateneinheit verändert zum Anzeigen, dass die alten Nutzlastdaten obsolet sind.
Ein bestimmter Transaktionsbezeichner wird zeitweise gespeichert zum Anzeigen, dass eine entsprechende Transaktion durchgeführt wird. Alle Aktualisierungsoperationen, die Teil der Transaktion sind, sind mit dem gleichen Transaktionsbezeichner oder einem unzweideutig zugeordneten Bezeichner markiert. Nachdem alle Aktualisierungsoperationen durchgeführt sind, wird die Transaktion abgeschlossen durch Entfernen des Transaktionsbezeichners von seiner zeitweisen Speicherung oder durch anderweitiges Markieren desselben zum Anzeigen der Abgeschlossenheit der Transaktion.
Unterstützung für mehrfache parallele Transaktionen, die auf nicht überlappenden Abschnitten der gespeicherten Daten innerhalb eines einzigen aktualisierbaren Blocks arbeiten, können hinzugefügt werden durch Zuteilen eines getrennten Zwischenspeicherortes für die zu aktualisierenden Daten für jede parallele Transaktion. Die parallelen Aktualisierungsoperationen werden innerhalb der Zwischenspeicherorte durchgeführt und lediglich danach werden die tatsächlichen Speicherorte aktualisiert.
Die Erfindung erlaubt die Handhabung von (in ein Dateisystem) auf eine sehr niedrige hierarchische Ebene zu bringenden Transaktionen, was wiederum viele Vorteile bietet. Die Applikationen, die höhere hierarchische Ebenen repräsentieren und das Dateisystem zum Speichern von Daten nutzen, müssen nicht wissen, wie die tatsächliche Transaktionsabwicklung implementiert ist. Die Dateisystemebenenimplementierung der Transaktionsabwicklung ist unabhängig von der Implementierung der Applikationen höherer Ebenen, was die Transaktionsabwicklung sehr stabil und auf einfache Weise anpassbar an verschiedene Arten von Applikationen macht. Die oberen hierarchischen Ebenen können weiterhin wiederum kompliziertere Operationen aufweisen, die auf dem Prinzip des Abschlusses entweder aller oder keines ihrer Teile beruhen.
Die neuen Merkmale, die als Kennzeichen der Erfindung angesehen werden, werden insbesondere in den beigefügten Ansprüchen dargelegt. Die Erfindung selbst jedoch, sowohl ihr Aufbau als auch ihre Betriebsweise zusammen mit zusätzlichen Zielen und Vorteilen derselben, wird am Besten verstanden anhand der folgenden Beschreibung von speziellen Ausführungsformen, wenn diese in Zusammenhang mit den beigefügten Zeichnungen gesehen werden.
1 veranschaulicht eine konventionelle Dateisystemaktualisierung,
2 veranschaulicht die bekannte Hierarchie von Konzepten in einem Flash-Speicher,
3 veranschaulicht eine bekannte Adressübersetzungsschicht,
4 veranschaulicht einen bekannten Weg des Aktualisierens von Daten,
5a veranschaulicht eine Anordnung für eine fehlersichere atomare Aktualisierungsoperation,
5b veranschaulicht ein Verfahren für einen fehlersicheren, atomaren Aktualisierungsablauf,
6 veranschaulicht eine Datenblockstruktur, die in Zusammenhang mit der Erfindung verwendet werden kann,
7 veranschaulicht ein Verfahren zum Durchführen von Flash-Speichertransaktionen,
8 veranschaulicht eine Anordnung zum Durchführen paralleler Flash-Speichertransaktionen,
9a bis 9h veranschaulichen ein Verfahren zum Durchführen paralleler Flash-Speichertransaktionen,
10a bis 10f veranschaulichen ein Verfahren zum Durchführen von Flash-Speichertransaktionen mit verketteten Schreiboperationen und
11 veranschaulicht eine Anordnung entsprechend einer Ausführungsform der Erfindung.
1 wurde oben bei der Beschreibung des Standes der Technik behandelt. Die folgende Beschreibung der Erfindung mit ihren vorteilhaften Ausführungsformen wird sich somit auf die 2 bis 11 konzentrieren.
Zum Liefern eines vollständigen Verständnisses der Erfindung werden wir zunächst einige bekannte Merkmale von Flash-Speichern und anderen Vorrichtungen, die einen logisch ähnlichen Aufbau und Betrieb aufweisen, beschreiben. Flash-Speicherdaten können allgemein nicht an der gleichen physikalischen Speicherposition aktualisiert werden ohne zunächst einen vollständigen logischen Block des Speichers zu löschen. Nach einer Löschung auf Blockebene besitzen alle Bits innerhalb des gelöschten Blocks einen gemeinsamen ersten konstanten Wert, gewöhnlich 1. Jedes Bit innerhalb des Blocks kann dann separat einmalig geschrieben werden durch Verändern seines Wertes auf einen zweiten konstanten Wert, gewöhnlich 0. Die einzige Art, danach den Wert des Bits zu verändern, ist das wiederholte Löschen des gesamten Blocks.
2 veranschaulicht in schematischer Weise eine Flash-Speichervorrichtung 201, welche unterteilt ist in Flash-Speicherlöschblöcke oder FMEBs. Im allgemeinen gibt es eine große positive ganzzahlige Anzahl M von FMEBs, von denen vier (202, 203, 204 und 205) getrennt in 2 gezeigt sind. Ein FMEB ist die kleinste logische Speichereinheit, die unabhängig von den anderen Teilen der Speichervorrichtung gelöscht werden kann. Die Größe eines FMEB hängt von dem Speichervorrichtungstyp ab und ist typischerweise von 4 kB bis 64 kB, wobei kB Kilobyte bedeutet.
Jeder FMEB besteht aus einem oder mehreren logischen Datenblöcken oder LDBs. 2 veranschaulicht die Unterteilung des ersten FMEB 202 in N LDBs, von denen fünf (206, 207, 208, 209 und 210) gesondert gezeigt sind. Ein LDB ist die kleinste aktualisierbare Dateneinheit in der logischen Flash-Datenblockvorrichtung. Konzeptionell ist sie gleich einem Daten sektor in einem Festplattenlaufwerk. Jeder LDB ist weiterhin unterteilt in einen LDB-Kopf oder LDBH, in 2 mit 211 bezeichnet, und einen Nutzlastdaten- oder LDB-Daten-Teil 212, bekannt durch das Akronym LDBD. Der erstere weist speziell ein LDB-Bezeichnerfeld 213 auf, dessen Inhalt verwendet wird zum zweifelsfreien Identifizieren jedes LDB und ein Statusfeld 214, das die Gültigkeit der Daten in dem entsprechenden physikalischen Speicherbereich anzeigt.
Da die Bitwerte innerhalb eines LDB lediglich einmal geschrieben werden können, ist das beliebige Aktualisieren der Nutzlastdaten in einem LDB lediglich möglich durch Schreiben des gesamten LDB an einen "jungfräulichen" oder "reinen" Speicherort, der seit dem letzten Blockebenenlöschen nicht angetastet wurde. Der alte Speicherort kann als unrein deklariert werden, indem dem Statusanzeiger innerhalb seines LDBH ein entsprechender Wert gegeben wird.
Vorher haben wir auf die Möglichkeit des Speicherns des LDB an mindestens zwei physikalisch getrennten Orten hingewiesen. Unter einem logischen Gesichtspunkt hat das physikalische Speicherformat keine Bedeutung, solange geeignete Umwandlungen vom Logischen in das Physikalische vorgesehen sind zum Erscheinen lassen des Datenblocks als einer logisch ganzheitlichen Einheit. Solche Umwandlungen und ihre praktischen Implementierungen sind als solche dem Fachmann bekannt.
3 veranschaulicht in schematischer Weise eine Schicht zur Übersetzung von einer logischen zu einer physikalischen Flash-Speicheradresse oder LTPTL, welches eine Art von Umwandlungstabelle ist, die eine physikalische Speicherortadresse jedem LDB-Bezeichner zuordnet. Wenn ein bestimmter LDB gelesen werden muss, wendet sich das System an die LTPTL zum Erhalt der physikalischen Speicheradresse, welche aktuell den speziellen LDB enthält. Die Prozedur ist als Abbildung einer logischen in eine physikalische Adresse oder LPAM bekannt. Die Aktualisierung ei nes LDB bedeutet, dass sich sein Ort in dem physikalischen Flash-Speicher ändert. Eine entsprechende Veränderung wird in der LTPTL so durchgeführt, dass die neue physikalische Speicheradresse darin auf den neuen Speicherort zeigt, der den aktualisierten LDB enthält.
Wie wir oben bemerkt haben, kann eine Speicheranordnung gemäß den oben unter Bezugnahme auf 2 und 3 erläuterten Prinzipien funktionieren, unabhängig davon, ob ihre physikalische Implementierung auf tatsächlicher Flash-Technik beruht oder nicht oder ob die physikalische Speicherung des Datenblockes an einem oder mehreren getrennten Orten stattfindet.
4 veranschaulicht einen bekannten Weg des Aktualisierens der Daten "am Ort" innerhalb eines Flash-Speichers. Bei dem ersten Schritt wird der Inhalt eines gesamten FMEB 401 in einen nichtpermanenten Speicher 402, welcher typischerweise ein Direktzugriffsspeicher oder RAM ist, gelesen. Solch ein Speicher legt einem wiederholten Hin- und Herwandeln von Bitwerten keine Beschränkungen auf, so dass der zweite Schritt die Aktualisierung der Daten innerhalb des RAM 402 ist. Bei dem dritten Schritt wird der ursprüngliche FMEB-Ort 401 gelöscht und bei dem vierten Schritt werden die aktualisierten Daten zurück an ihren ursprünglichen Flash-Speicherort geschrieben. Wenn irgendwelche fatalen Fehler während entweder des dritten oder des vierten Schrittes auftreten, ist es wahrscheinlich, dass gültige Daten verloren sind, da sie lediglich in dem nichtpermanenten Speicher vorhanden sind. Ein zusätzlicher Nachteil des Verfahrens von 4 ist der, dass die Aktualisierungsart Löschen-Beim-Schreiben im allgemeinen sehr ineffizient ist und ein frühes Altern des Flash-Speichers verursachen kann.
5a und 5b veranschaulichen eine fehlersichere atomare Aktualisierungsprozedur eines LDB. Zwei physikalische Speicherorte 501 und 502 der Größe eines LDB sind gezeigt. Wir werden annehmen, dass eine Menge von erlaubten Werten für das Statusfeld in nerhalb des LDBH definiert wurde, so dass zumindest solche Zustände wie "nicht verwendet", "beschrieben", "gültig", "unrein" und "defekt" bezeichnet werden können. Von diesen bedeutet der Zustand "defekt", dass der entsprechende physikalische Speicherort nicht richtig funktioniert, so dass er überhaupt nicht verwendet werden sollte. Der Zustand "defekt" bezieht sich auf die allgemeine Verwendung von Speichervorrichtungen und hat keine Bedeutung für die vorliegende Erfindung. Zusätzlich erscheint in 5 ein bestimmter nichtpermanenter Speicher 503, der als ein Arbeitsraum verfügbar ist.
Der erste Schritt 551 des Aktualisierens der in dem Nutzlastteil des LDB gespeicherten Daten, die aktuell an einem ersten Speicherort 501 liegen, ist das Lesen des Nutzlastteils in den nichtpermanenten Speicher 503. Die Aktualisierung der Daten in dem nichtpermanenten Speicher 503 bildet den nächsten Schritt 552. Bislang ähnelt das Verfahren dem bekannten, nicht fehlersicheren Verfahren von 4. Die aktualisierten Daten werden jedoch nicht an denselben physikalischen Speicherort geschrieben, sondern an einen frischen Speicherort 502. Eine sorgfältig entworfene Abfolge von aufeinanderfolgenden Schritten wird beachtet zum Sicherstellen, dass eine gültige Kopie der Daten immer verfügbar ist, sogar nach einem unerwarteten Systemfehler.
Beim Schritt 553 wird das Statusanzeigefeld 522 des zweiten Speicherortes 502 von "nicht verwendet" auf "beschrieben" geändert. Beim Schritt 554 wird der LDB-Bezeichner von dem LDB-Bezeichnerfeld 511 des ersten Speicherortes 501 zu dem LDB-Bezeichnerfeld 521 des zweiten Speicherortes 502 kopiert. Der LDB-Bezeichner kann von dem ersten Speicherort zusammen mit den Nutzlastdaten schon bei dem Schritt 551 gelesen worden sein oder er kann vorher von anderswo erhalten worden sein (z.B. der LTPTL), so dass ein tatsächlicher Lesevorgang von dem ersten Speicherort bei dem Schritt 554 am vorteilhaftesten nicht mehr notwendig ist. Konzeptionell ist es jedoch am einfachsten, zu denken, dass ein Teil der Prozedur des Vorbereitens des neuen Speicherortes 502 das direkte Kopieren des LDB-Bezeichners von dem alten Speicherort 501 ist. Bei dem Schritt 555 werden die aktualisierten Nutzlastdaten in das Nutzlastdatenfeld 523 des neuen Speicherortes 502 geschrieben. Die gegenseitige Reihenfolge der Schritte 554 und 555 kann ohne merkbare Auswirkungen auf die Anwendbarkeit der Erfindung geändert werden.
Erst nachdem das Schreiben von sowohl dem LDB-Bezeichner als auch den aktualisierten Nutzlastdaten an den neuen Speicherort 502 erfolgreich abgeschlossen ist, wird die Statusanzeige in dem entsprechenden Feld 522 des neuen Speicherortes 502 von "geschrieben" auf "gültig" im Schritt 556 geändert. Danach wird im Schritt 557 die Abbildung der logischen auf die physikalische Flash-Speicheradresse aktualisiert, so dass sie den LDB-Bezeichner (der nun identisch in den beiden Bezeichnerfeldern 511 und 521 des alten bzw. neuen Speicherortes erscheint) dem neuen physikalischen Speicherort 502 zuordnet. Im Schritt 558 wird die Statusanzeige in dem entsprechenden Feld 512 des alten Speicherortes 501 von "gültig" auf "unrein" geändert. Zu einem späteren Zeitpunkt kommt ein Schritt 559, bei dem der FMEB (nicht gezeigt), zu dem der alte Speicherort gehört, gelöscht werden wird, was gleichzeitig die Statusanzeige in dem entsprechenden Feld 512 des alten Speicherortes 501 von "unrein" auf "nicht verwendet" verändert.
Die Lage des Schrittes, in dem die Abbildung der logischen auf die physikalische Flash-Speicheradresse aktualisiert wird, ist nicht kritisch. Am vorteilhaftesten wird sie durchgeführt nach dem Schritt, in dem die aktualisierten Nutzlastdaten an den neuen Speicherort geschrieben werden, und vor dem Schritt, in dem der alte Speicherort gelöscht wird, oder zumindest bevor auf die aktualisierten Nutzlastdaten das nächste Mal zugegriffen wird. Im folgenden diskutieren wir einige Erwägungen, die sich auf die Lage des Aktualisierungsschrittes der Abbildung der logischen in die physikalische Flash-Speicheradresse beziehen.
Die Anwendbarkeit des in 5a und 5b veranschaulichten Verfahrens auf die Transaktionsabwicklung entsteht im allgemeinen durch die Tatsache, dass zu jedem Zeitpunkt der Zeit eine bestimmte Kopie der verfügbaren Daten in einem nichtflüchtigen Flash-Speicher ist. Die folgende Zustandstabelle veranschaulicht die Werte in den Statusanzeigefeldern nach jedem in 5b gezeigten Schritt.
Tabelle 1
Die allgemeine Regel zum Wiederanlaufen nach einem unerwarteten schwerwiegenden Fehler ist es, die Daten von dem Speicherort zu wählen, für den das LDB-Statusanzeigefeld anzeigt, dass die Daten gültig sind. Wir sehen jedoch von Tabelle 1, dass nach dem Ende des Schrittes 556 und vor dem Beginn des Schrittes 558 es einen kurzen Zeitraum gibt, während dem beide Speicherorte beanspruchen, die gültigen Daten aufzuweisen, obwohl die Daten an dem neuen Speicherort aktualisiert sind und die Daten an dem alten Speicherort es nicht sind. Eine einfache Regel zum Wiederanlaufen aus solch einer Situation ist es, zufällig einen der Speicherorte zu wählen, deren LDB-Bezeichner gleich sind, und den andern wegzuwerfen, d.h. seine Statusanzeige von "gültig" nach "unrein" zu verändern. Wenn dadurch der alte Speicherort als gültig gewählt wird, bleiben die nicht aktualisierten Daten gültig und die versuchte Aktualisierung wird so angesehen, als habe sie überhaupt nicht stattgefunden. Wenn der neue Speicherort gewählt wird, wird die versuchte Aktualisierung so angesehen, als sei sie erfolgreich gewesen.
Es gibt einen Weg der Handhabung der "Gültig + Gültig"-Situation, der nur wenig komplizierter ist als die zufällige Auswahl, aber die mit der zufälligen Auswahl verbundene Unbestimmtheit durch einen vollständigen Determinismus ersetzt. Die LDBs können so spezifiziert werden, dass sie eine Anzahl von Bits aufweisen, welche als zyklische Indikatoren in der Reihenfolge entsprechend des Alters dienen. Der einfachste mögliche zyklische Indikator besteht aus zwei Bits. Jedes Mal wenn ein LDB in einen Flash-Speicher geschrieben wird, wird der Wert der Indikatorbits von ihrem ursprünglichem Wert gemäß einem zyklischen Muster erhöht, am einfachsten entsprechend dem Muster 00 -> 01 -> 10 -> 11 -> 00 und so weiter (oder, wenn jedes Mal die Veränderung eines einzigen Bitwertes bevorzugt wird, 00 -> 01 -> 11 -> 10 -> 00 und so weiter). Wenn zwei Kopien des gleichen LDB in einem Speicher gefunden werden, ist durch Vergleichen ihrer zyklischen Indikatorbits einfach zu sehen, welcher von ihnen älter ist und welcher jünger ist. Die Verwendbarkeit eines zyklischen Indikators mit einer bestimmten Anzahl von Bits beruht auf der Annahme, dass alte Kopien des gleichen LDB als "unrein" markiert werden oder gelöscht werden, bevor der Zyklus der Indikatorwerte erschöpft ist. Je größer die Anzahl bei dem zyklischen Indikator ist, desto länger ist der Zyklus der Werte und desto länger ist entsprechend die "LDB-Historie", welche durch Betrachten der zyklischen Indikatorwerte unzweifelhaft verfolgt werden kann.
Unterstreichung und Fettdruck heben in Tabelle 1 den Speicherort hervor, von dem Daten gültig gelesen werden können.
Basierend auf der oben gegebenen Beschreibung einer fehlersicheren, atomaren Aktualisierungsprozedur werden wir nun eine vorteilhafte Ausführungsform einer vollständigen Flash-Speichertransaktion beschreiben. Nehmen wir an, dass zu dem LDB-Kopf jedes LDB in dem System ein weiteres Feld hinzugefügt ist. 6 veranschaulicht in schematischer Weise einen LDB 601, bei dem das Kopfteil ein LDB-Bezeichnerfeld 602, ein LDB-Statusanzeigefeld 603 und ein Transaktions-Bezeichnerfeld 604 aufweist. Neben wir weiterhin an, dass die erlaubten Werte des LDB-Statusanzeigefeldes 603 den Zuständen "nicht verwendet", "beschrieben", "transaktionsbeschrieben", "gültig", "unrein" und "defekt" entsprechen, bei denen der Zustand "transaktionsbeschrieben" eine Hinzufügung zu dem ist, was oben beschrieben wurde. Zusätzlich nehmen wir an, dass das System konzeptionell eine Auswahl von Transaktionsbezeichnern zu seiner Verfügung hat, so dass jeder Transaktionsbezeichner entweder in Verwendung ("aktiv") oder frei ("inaktiv") zu einem gegebenen Zeitpunkt ist, und dass zumindest ein LDB als der Speicherbereich der aktiven LDBs zugewiesen ist. Wir werden auf diesen speziellen LDB als den LDB#T bezug nehmen.
Nun bezugnehmend auf 7 wird beim Schritt 701 durch Aktivieren eines Transaktionsbezeichners eine Transaktion gestartet, d.h. durch Auswählen eines bis dato inaktiven Transaktionsbezeichners und Schreiben desselben in LDB#T. Wir werden auf diesen speziellen Transaktionsbezeichner als den #TID bezug nehmen. Das Schreiben wird bewirkt durch Verwenden der oben mit Bezugnahme auf 5a und 5b beschriebenen fehlersicheren, atomaren Aktualisierungsprozedur. Nach dem erfolgreichen Aktivieren des #TID wird die Transaktion als gestartet angesehen.
Das Konzept des Aktivierens eines Transaktionsbezeichners ist von allgemeiner Bedeutung für die vorliegende Erfindung und es sollte verständlich sein, dass das Schreiben desselben in LDB#T nicht die einzig mögliche praktische Implementierung ist. Innerhalb des Kontextes der vorliegenden Erfindung wird die Aktivierung eines Transaktionsbezeichners so verstanden, dass sie all solche Prozeduren umfasst, die die Wirkung des Setzens eines Transaktionsbezeichners in einen bestimmten ersten Zustand haben, von dem er unzweifelhaft wiederhergestellt werden kann, sogar nach einem Systemfehler. Das entsprechende Deaktivieren eines bestimmten Transaktionsbezeichners meint das Setzen desselben in einen bestimmten zweiten Zustand, welcher unzweideutig von dem ersten Zustand unterscheidbar ist, sogar nach einem Systemfehler. Alle solchen Transaktionsbezeichner, die aktiviert wurden und noch nicht nachfolgend deaktiviert wurden, können als aktive Transaktionsbezeichner bezeichnet werden.
Die tatsächliche Aktualisierung der Daten in dem Kontext einer Flash-Speichertransaktion besteht aus einer Anzahl von Aktualisierungsvorgängen, von denen jeder einen einzelnen LDB betrifft. Beim Schritt 702 wird der Inhalt eines durch einen bestimmten LDB-Bezeichner LDB#X identifizierten LDB von einem ersten Flash-Speicherort in einen nichtpermanenten Arbeitsspeicher gelesen und beim Schritt 703 werden die in dem Nutzlastdatenteil desselben enthaltenen Daten aktualisiert. Beim Schritt 704 wird das Statusanzeigefeld eines frischen, zweiten Flash-Speicherortes von "nicht verwendet" nach "beschrieben" verändert und beim Schritt 705 wird der LDB#X in das LDB-Bezeichnerfeld des zweiten Speicherortes geschrieben. Beim Schritt 706 wird der #TID in das Transaktionsbezeichnerfeld des zweiten Speicherortes geschrieben und beim Schritt 707 werden die aktualisierten Daten in den Nutzlastdatenteil des zweiten Speicherortes geschrieben. Die Schritte 705, 706 und 707 können ebenfalls in einer anderen Reihenfolge zueinander sein. Nachdem der zweite Speicherort erfolgreich mit dem korrekten LDB-Bezeichner (LDB#X), dem Transaktionsbezeichner (#TID) und den aktualisierten Nutzlastdaten versehen wurde, wird beim Schritt 708 der Wert seines Statusanzeigefeldes von "beschrieben" nach "transaktionsbeschrieben" geändert.
Beim Schritt 709 gibt es eine Überprüfung, ob der beendete LDB-Aktualisierungsvorgang der letzte der Flash-Speichertransaktion war. Ein negativer Befund bei Schritt 709 bedeutet, dass es noch weitere LDB-Aktualisierungsvorgänge gibt, die durchzuführen sind in dem Kontext der aktuellen Transaktion, so dass zum Schritt 702 zurückgekehrt wird mit der Ausnahme, dass der Startpunkt ein unterschiedlicher LDB sein kann als vorher, und die aktualisierten Ergebnisse werden an einen unterschiedlichen zweiten Speicherort als vorher geschrieben. Ein positiver Befund bei Schritt 709 bedeutet, dass die Datenaktualisierung, die zu der aktuellen Transaktion gehört, beendet wurde, so dass die Transaktion zu ihrer Abschließungsphase fortschreiten kann.
Die Abschließungsphase der Flash-Speichertransaktion, die in 7 veranschaulicht ist, besteht aus Schritt 710, bei dem der #TID von dem LDB#T entfernt wird. Die fehlersichere, atomare Aktualisierungsprozedur wird ebenfalls zum Bewirken des Entfernens verwendet. An diesem Punkt sollte bemerkt werden, dass alle alten Speicherorte, die Gegenstand der Aktualisierung in Zusammenhang mit der Transaktion waren, durch ihre Statusanzeigefelder noch als gültig deklariert werden. Deshalb fährt die Transaktion mit der Schleife bestehend aus den Schritten 711, 712, 713 und 714 fort. Beim Schritt 711 wird die Abbildung von der logischen zur physikalischen Flash-Speicheradresse aktualisiert, so dass sie den LDB-Bezeichner LDB#X dem neuen physikalischen Speicherort zuordnet. Die tatsächliche Lage des Adressabbildungs-Aktualisierungsschrittes in Bezug zu den anderen Verfahrensschritten ist von keiner Bedeutung, wie vorher in Zusammenhang mit der fehlersicheren, atomaren Aktualisierungsprozedur erläutert wurde. Beim Schritt 712 wird die Statusanzeige eines bestimmten ersten Speicherortes, der die alte nicht aktualisierte Version eines bestimmten Datenblockes, der als LDB#X bekannt ist, beherbergt, von "gültig" nach "unrein" geändert.
Beim Schritt 713 wird die Statusanzeige eines entsprechenden zweiten Speicherortes, der die neue, aktualisierte Version des Datenblockes, der als LDB#X bekannt ist, beherbergt, von "transaktionsbeschrieben" nach "gültig" geändert. Es ist nicht notwendig, explizit den Schritt 713 durchzuführen, wenn der gleiche Transaktionsbezeichner nicht wiederverwendet wird; wir werden später mehr über den verzögerten Schritt 713 erläutern. Schritt 714 ist eine Überprüfung, ob alle LDBs, die der abgeschlossenen Transaktion zugeordnet waren, die in den Schritten 711, 712 und 713 gemachten Änderungen durchlaufen haben; ein negativer Befund bedeutet eine Rückkehr zu Schritt 711 zum Prozessieren eines anderen erster/zweiter Speicherortpaares und ein positiver Befund bei Schritt 714 bedeutet, dass die Prozessierung der Transaktion abgeschlossen wurde.
Die folgende Zustandstabelle veranschaulicht die Werte in den Statusanzeigefeldern an einem bestimmten alten und neuen Speicherort nach jedem Schritt, der in 7 gezeigt ist. Abkürzungen U für "nicht verwendet", W für "beschrieben", T für "transaktionsbeschrieben", V für "gültig" und D für "unrein" wurden der Kürze halber verwendet.
TABELLE 2
Fettdruck und Unterstreichung heben in Tabelle 2 den Speicherort hervor, an dem die gültigen Daten zu einem gegebenen Zeitpunkt verfügbar sind. Analysieren wir die Gültigkeit der Daten in dem Kontext der allgemeinen Regeln der Abwicklung von Transaktionen.
Vorher haben wir erwähnt, dass alle Aktualisierungsoperationen einer Transaktion entweder erfolgreich sein müssen oder alle zusammen unerledigt bleiben müssen. Die Grenzlinie zwischen diesen beiden Alternativen ist die Abschließungsphase der Transaktion. In 7 bildet Schritt 710 den Abschließungsschritt.
Wenn ein schwerwiegender Systemfehler auftritt, bevor die Transaktion den Schritt 710 erreicht hat, d.h. bevor der Transaktionsbezeichner #TID von dem zugewiesenen Speicher der aktiven Transaktionsbezeichner entfernt wurde, ist es grundsätzlich nicht sicher, ob alle LDB-Aktualisierungen korrekt durchgeführt wurden oder nicht. Die einzig vernünftige Alternative ist deshalb das Zurücksetzen der Transaktion, d.h. dass Aufheben aller Aktualisierungsoperationen. Mit anderen Worten, bei dem nächsten Hochfahren des Systems nach dem schwerwiegenden Fehler werden alle solche physikalischen Speicherorte als unrein markiert, welche eines der folgenden beiden Kriterien erfüllen:

– Der Wert ihrer Statusanzeigefelder zeigt den Status "beschrieben" an
– Der Wert ihrer Statusanzeigefehler zeigt den Status "transaktionsbeschrieben" an und der Transaktionsbezeichner, der in ihren Transaktionsbezeichnerfeldern gefunden wurde, erscheint ebenfalls in dem zugewiesenen Speicher der aktiven Transaktionsbezeichner.

In einigen Fällen erfüllen die als unrein zu deklarierenden physikalischen Speicherorte ebenfalls das Kriterium, dass der Wert ihres LDB-Bezeichnerfeldes ebenfalls in dem entsprechenden Feld eines anderen (alten) physikalischen Speicherortes erscheint. Solch ein Merkmal ist jedoch aus mehreren Gründen nicht ein zuverlässiges Kennzeichen von als unrein zu deklarierenden physikalischen Speicherorten. Der wichtigste von ihnen ist die typische Unsicherheit, für wie lange der alte physikalische Speicherort in dem Zustand verbleiben wird, bevor er gelöscht wird. Ein Aufräumprogramm im Hintergrund überwacht kontinuierlich den Zustand des Flash-Speichers und versucht freien Speicherort zu schaffen durch Umherbewegen von Datenblöcken und Löschen von FMEBs. Zusätzlich kann es in einigen Fällen passieren, dass der Systemfehler auf einer sehr frühen Stufe des Vorgangs stattfindet, auf der es keine "alten" Kopien der LDBs gibt, da der Flash-Speicher rein war, bevor die ersten durchzuführenden Transaktionen das Schreiben der "neuen" Kopien in den Flash-Speicher bewirkten.
Wenn ein schwerwiegender Systemfehler nach der Vollendung von Schritt 710 auftritt, d.h. nachdem der Transaktionsbezeichner #TID von dem zugewiesenen Speicher der aktiven Transaktionsbezeichner entfernt wurde, ist es sicher, dass alle LDB-Aktualisierungen korrekt durchgeführt wurden. Deshalb ist es sicher, zu deklarieren, dass die Transaktion erfolgreich ausge führt wurde und die aktualisierten LDBs können von den "neuen" Speicherort bei dem nächsten Hochfahren des Systems gelesen werden. In diesem Fall sind all jene physikalischen Speicherorte als unrein markiert, die die folgenden drei Kriterien erfüllen:

– Der Wert ihres LDB-Bezeichnerfeldes erscheint ebenfalls in dem entsprechenden Feld eines anderen (neuen) physikalischen Speicherortes
– Der Wert ihrer Statusanzeigefelder bezeichnet den Zustand "gültig"
– Der in dem Transaktionsbezeichnerfeld des anderen (neuen) physikalischen Speicherortes mit dem gleichen LDB-Bezeichner gefundene Transaktionsbezeichner erscheint nicht in dem zugewiesenen Speicher der aktiven Transaktionsbezeichner.

Zusätzlich sind all jene physikalischen Speicherorte als gültig markiert, die die folgenden beiden Kriterien erfüllen:

– Der Wert ihrer Statusanzeigefelder zeigt den Zustand "transaktionsbeschrieben" an
– Der Transaktionsbezeichner, der in ihrem Transaktionsbezeichnerfeld gefundene Transaktionsbezeichner erscheint nicht in dem zugewiesenen Speicher der aktiven Transaktionsbezeichner.

Der oben erwähnte Schritt des Veränderns der "Transaktionsbeschrieben"-Blöcke zu "gültig" kann verzögert werden, bis entweder der gleiche TID, der in ihrem Transaktionsbezeichnerfeld gespeichert ist, beim nächsten Mal aktiviert wird oder diese speziellen Blöcke einer neuen Aktualisierung unterzogen werden.
Beim Analysieren, was geschieht, wenn ein schwerwiegender Systemfehler auftritt, während das System den Schritt 710 ausführt, müssen wir auf die Beschreibung der fehlersicheren, atomaren Aktualisierungsoperation, die in Zusammenhang mit 5a und 5b beschrieben wurde, Bezug nehmen. Dort gaben wir Regeln an zur Wiederherstellung von einem unerwarteten Fehler, so dass in den meisten Fällen es keine Gelegenheit für eine Unbestimmtheit gibt. Lediglich dann, wenn wir die zufällige Auswahl von entweder dem alten oder dem neuen physikalischen Speicherort zulassen, wenn beide als gültig bezeichnet sind, kann es geschehen, dass der Zustand, in dem der Flash-Speicher in dem Augenblick des schwerwiegenden Systemfehlers zurückgelassen wurde, nicht eindeutig die Auswahl von entweder der Zurücksetzung oder der Abschließung einer unterbrochenen Transaktion bei dem nächsten Systemstart bestimmt. In dem Falle der Aktualisierung des LDB#T können wir natürlich festlegen, dass in solch einer "Gültig + Gültig"-Situation z.B. der Speicherort mit einer kleineren (größeren) Anzahl von darin gespeicherten Transaktionsbezeichnern immer ausgewählt wird, so dass es wahrscheinlicher (weniger wahrscheinlich) ist, dass Schritt 710 als abgeschlossen interpretiert werden wird. Zum Prioritätszeitpunkt dieser Anmeldung ist der wahrscheinlich vorteilhafteste Weg der, zyklische Indikatoren als einen Teil des Vorgangs der Aktualisierung des LDB#T zu verwenden, so dass die oben beschriebene Zufälligkeit beseitigt werden kann.
Als nächstes werden wir die Anwendbarkeit der Erfindung auf parallele Transaktionen beschreiben. Eines der grundlegenden Prinzipien der Transaktionsabwicklung ist jenes, dass zwei parallelen Transaktionen niemals gestattet wird, genau den gleichen logischen Datenbereich parallel zu aktualisieren. Wir können jedoch zwei oder mehr parallelen Transaktionen das Aktualisieren nicht überlappender Abschnitte eines bestimmten LDB parallel erlauben, solange die Abschließungsphasen der Transaktionen seriell stattfinden, d.h. die Abschließungsphase einer bestimmten der parallelen Transaktionen kann erst beginnen, wenn gleichzeitig keine andere Abschließungsphase einer weiteren der parallelen Transaktionen abläuft.
Der Einfachheit halber werden wir lediglich die Wirkung von parallelen Transaktionen auf einen einzigen LDB beschreiben. Nichts hindert jedoch daran, parallele Transaktionen auf die Aktuali sierung von sogar einer sehr großen Anzahl von LDBs anzuwenden. Die folgende Beschreibung wird leicht so verallgemeinert, dass sie solche Fälle abdeckt.
8 und 9a bis 9j veranschaulichen eine Anordnung und ein Verfahren zum Durchführen paralleler Transaktionen unter Verwendung eines Flash-Speichers. In 8 ist ein alter physikalischer Speicherort 800, eine Anzahl von neuen physikalischen Speicherorten und eine Anzahl von nichtpermanenten (RAM) Speicherpuffern gezeigt. Zum Abwickeln paralleler Transaktionen sind vorteilhafterweise so viele neue physikalische Speicherorte und so viele nichtpermanente Speicherpuffer vorhanden wie es parallele Transaktionen gibt, die eine Wirkung auf einen einzelnen LDB haben. Hier nehmen wir an, dass die Anzahl von parallelen Transaktionen drei ist, so dass es drei neue physikalische Speicherorte 810, 820 und 830 und drei nichtpermanente Speicherpuffer 841, 842 und 843 gibt. Die drei parallelen Transaktionen sind mit bestimmten Transaktionsbezeichnern TID#A, TID#B und TID#C verknüpft. Allgemein können wir die Anzahl von parallelen Transaktionen mit einer positiven ganzen Zahl N bezeichnen. Die LDB-Struktur ist die gleiche wie oben, d.h. in dem LDB-Kopfteil gibt es Felder für einen LDB-Bezeichner, einen LDB-Zustandsindikator und einen Transaktionsbezeichner. Bezeichnen wir den LDB, der das Ziel des parallelen Aktualisierens ist, mit LDB#X. Der Inhalt seines TID-Feldes beim Beginn der Ausführung der parallelen Transaktionen ist nicht von Bedeutung, so dass wir ihn mit TID#? bezeichnen können.
Die Anforderung, dass es so viele neue physikalische Speicherorte und so viele nichtpermanente Speicherpuffer gibt wie es parallele Transaktionen gibt, kann erleichtert werden, wenn die parallelen Transaktionen zu sehr unterschiedlichen Zeiten aktiv sind, so dass einige von ihnen es relativ früh bis zum Abschluss schaffen und die ihnen zugewiesenen Ressourcen freigegeben werden können. In ähnlicher Weise kann die Größe der nichtpermanenten Speicherpuffer so optimiert sein, dass jeder nichtpermanente Speicherpuffer lediglich eine Größe aufweist, die groß genug ist zum Enthalten jener Datenbits, die die spezielle Transaktion, die den nichtpermanenten Speicherpuffer verwendet, aktualisieren darf. Speziell die nichtpermanenten Speicherpuffer brauchen nicht Speicherplatz für die Datenkopffelder der zu aktualisierenden LDBs aufweisen; diese Tatsache wird in den Zeichnungen hervorgehoben durch Zeichnen der entsprechenden Teile mit gestrichelten Linien. Tatsächlich ist es möglich, die Transaktionen sogar vollständig ohne nichtpermanente Speicherpuffer zu realisieren, indem ein frischer Flash-Speicherort für jeden Schritt verwendet wird, bei dem neue Daten alte Daten in dem Verlauf der Aktualisierung ersetzen. Solch eine "von-Flash-zu-Flash"-Aktualisierung ist jedoch gewöhnlich in hohem Maße ineffizient im Vergleich zu Lösungen, bei denen Daten von einer logischen Flash-Speichervorrichtung in relativ großen Blöcken in einen nichtpermanenten Arbeitsspeicher gelesen werden, die gesamte Aktualisierung in dem nichtpermanenten Arbeitsspeicher vorgenommen wird und aktualisierte Blöcke wieder in den Flash geschrieben werden.
Die Datenbits innerhalb der nicht aktualisierten Kopie von LDB#X, welche eine bestimmte Transaktion TID#i aktualisieren darf, sind mit i1 markiert, wobei i = A, B, C. Hier nehmen wir an, dass die parallelen Transaktionen mehr oder weniger gleichzeitig gestartet werden, dies aber nicht eine bindende Anforderung ist: eine Transaktion kann für eine beachtliche Zeit vonstatten gehen, bevor eine andere gestartet wird. In unserem Beispiel beginnt die Abwicklung der parallelen Transaktionen durch Schreiben der Transaktionsbezeichner TID#A, TID#B und TID#C in den Speicher der aktiven Transaktionsbezeichner 850. Die Aktualisierung der Daten beginnt durch Lesen des LDB#X von dem alten physikalischen Speicherort 800 in alle zugeordneten nichtpermanenten Speicherpuffer 841, 842 und 843. 9a veranschaulicht die Situation nach den Lesevorgängen: auf dieser Stufe wurden noch keine Aktualisierungen der Daten vorgenommen, da die Transaktionen gleichzeitig gestartet wurden.
Jeder der parallelen Transaktionen wird lediglich gestattet, den mit ihr in einem der nichtpermanenten Speicherpuffer verknüpften Datenabschnitt zu aktualisieren, so dass wir annehmen können, dass TID#A die A Bits in Puffer 841 aktualisiert, TID#B die B Bits in Puffer 842 aktualisiert und TID#C die C Bits in Puffer 843 aktualisiert. Zu dieser Zeit werden keine Veränderungen des Inhalts der neuen physikalischen Speicherorte 810, 820 und 830 vorgenommen.
9b veranschaulicht die Situation in dem Moment, wenn die schnellste der parallelen Transaktionen (sagen wir Transaktion TID#A) die gesamte Aktualisierung beendet hat, die in dem entsprechenden nichtpermanenten Speicherpuffer 841 vorgenommen werden muss: alle A1-Bits wurden mit aktualisierten A2-Bits ersetzt. Der Inhalt des nichtpermanenten Speicherpuffers wird dann auf den entsprechenden neuen Flash-Speicherort 810 geschrieben entsprechend den Verfahrensschritten, die vorher in Zusammenhang mit einer einzelnen Transaktion erläutert wurden. 9b zeigt, wie das Schreiben durch Verändern des Zustandsbezeichners von "nicht verwendet" nach "beschrieben" und durch Schreiben des LDB-Bezeichners LDB#X und des Transaktionsbezeichners TID#A in die entsprechenden Datenkopffelder gestartet wurde.
9c zeigt, wie der Inhalt des ersten nichtpermanenten Speicherpuffers 841 an den entsprechenden neuen Flash-Speicherort 810 geschrieben wurde. Zusätzlich zeigt 9c einen Schritt, welcher ein wichtiger Teil der Abwicklung von parallelen Transaktionen ist: die Aktualisierungen A1 -> A2 durch die erste Transaktion werden ebenfalls in die anderen Speicherpuffer 842 und 843 kopiert. Der Zustandsbezeichner des fertig gestellten neuen Flash-Speicherortes 810 wird von "beschrieben" nach "transaktionsbeschrieben" geändert.
9d zeigt zwei weitere Entwicklungsschritte bei der Abarbeitung der parallelen Transaktionen. Die vollständige Transaktion TID#A wird abgeschlossen durch Entfernen ihres Bezeichners von dem Speicher der aktiven Transaktionsbezeichner 850, durch Verändern des Statusanzeigers des alten physikalischen Speicherortes 800 von "gültig" nach "unrein" und durch Verändern der Statusanzeige des vollendeten neuen physikalischen Speicherortes von "transaktionsbeschrieben" nach "gültig". Gleichzeitig geschieht es, dass die zweitschnellste Transaktion TID#B eine Stufe erreicht, bei der alle Aktualisierungen in dem nichtpermanenten Speicherpuffer 842 vorgenommen wurden, so dass das Schreiben in den entsprechenden Flash-Speicherort 820 beginnen kann durch Verändern des Zustandsbezeichners von "nicht verwendet" nach "beschrieben" und durch Schreiben des LDB-Bezeichners LDB#X und des Transaktionsbezeichners TID#B in die geeigneten Datenkopffelder.
9e und 9f zeigen Wiederholungen der in 9c bzw. 9c gezeigten Schritte mit den naturgemäßen Ausnahmen:

– In 9e wird das Schreiben des zweiten Flash-Speicherortes 820 abgeschlossen und es sind die B1 -> B2-Aktualisierungen, die in die verbleibenden nichtpermanenten Speicherpuffer kopiert werden (der Puffer 841 wurde am vorteilhaftesten auf dieser Stufe freigegeben, was dadurch angedeutet ist, dass er in Klammern gesetzt ist)
– In 9f wird die Transaktion TID#B abgeschlossen (was den vorher gültigen physikalischen Speicherort 810 unrein macht und den neuesten vollständigen physikalischen Speicherort 820 gültig macht) und es ist die letzte Transaktion TID#C, die die Aktualisierung in dem nichtpermanenten Speicherpuffer 843 beendet, so dass das Schreiben an den dritten Flash-Speicherort 830 beginnen kann.

9g zeigt eine Wiederholung der in 9e gezeigten Schritte mit den naturgemäßen Ausnahmen, dass das Schreiben an den dritten Flash-Speicherort 830 abgeschlossen wird und die C1 -> C2-Aktualisierungen nicht in irgendwelche weiteren nichtpermanenten Speicherpuffer kopiert werden, da alle weiteren nichtpermanenten Speicherpuffer am vorteilhaftesten in diesem Stadium freigegeben sind. In 9h wird die vollständige Transaktion TID#C abgeschlossen durch Entfernen des Bezeichners TID#C von dem Speicher der aktiven Transaktionsbezeichner 850, durch Verändern des entsprechenden Zustandsbezeichners von "transaktionsbeschrieben" nach "gültig" und Markieren des vorher gültigen physikalischen Speicherortes 820 als "unrein".
Wie bei der früher beschriebenen atomaren Aktualisierung ist die Lage der Schritte, bei denen die LTPTL-Tabelle aktualisiert wird, um auf die neueste gültige Kopie eines bestimmten LDB zu zeigen, nicht wichtig, obwohl es am vorteilhaftesten stattfindet, nachdem die neueste gültige Kopie in den Flash-Speicher geschrieben wurde und bevor die alte, ungültige Kopie gelöscht wird.
Die Einhaltung der allgemeinen Transaktionsabwicklungsregeln durch die oben beschriebene Prozedur wird leicht erkannt durch das getrennte Analysieren der Abschließungsphasen der parallelen Transaktionen. All jene Transaktionen, deren Bezeichner von dem Speicher der aktiven Transaktionsbezeichner 850 vor einem eventuellen Systemfehler gelöscht wurden, bleiben beim nächsten Start des Systems abgeschlossen, da ein Flash-Speicherort mit den durch solche Transaktionen aktualisierten Daten in einem Zustand "gültig" gefunden wird. All jene Transaktionen, die ihre Bezeichner noch als aktiv gespeichert hatten, werden zurückgesetzt.
Bei der Beschreibung der Ausführungsformen der Erfindung haben wir bislang angenommen, dass die gesamte Aktualisierung der Daten in dem nichtpermanenten Arbeitsspeicher durchgeführt wird nach dem Schritt des Lesens des alten LDB von der logischen Flash-Speichervorrichtung und vor dem Schreiben der neuen, vollständig aktualisierten Version in den Flash. Aus Gründen der Vollständigkeit werden wir als nächstes unter Bezugnahme auf 10a bis 10f eine Ausführungsform der Erfindung beschreiben, bei der sogenannte verkettete Schreibvorgänge an dem Flash-Speicher verwendet werden. Zum Einfachhalten der Beschreibung werden wir lediglich eine einzige, nichtparallele Transaktion betrachten, obwohl das gleiche Prinzip sehr gut ebenfalls für parallele Transaktionen geeignet ist.
10a veranschaulicht einen alten physikalischen Speicherort 1000 und zwei neue physikalische Speicherorte 1010 und 1020 bei einer Startphase, in der Daten von dem ersten erwähnten in einen nichtpermanenten Arbeitsspeicher (nicht gezeigt) für die erste Aktualisierung gelesen werden. Bei dem in 10b gezeigten Schritt sind die durch eine als TID#Y bekannte Transaktion durchgeführten ersten Aktualisierungen fertig, so dass das Schreiben des teilweise aktualisierten LDB an den ersten neuen physikalischen Speicherort 1010 beginnt. Hier nehmen wir wieder an, dass die Datenkopffelder zunächst beschrieben werden und die Statusanzeige den Wert "beschrieben" erhält. Bei dem in 10c gezeigten Schritt wurde das Schreiben der teilweise aktualisierten Kopie beendet, so dass die Statusanzeige derselben nach "transaktionsbeschrieben" geändert wurde. Gleichzeitig nähern sich die zweiten Aktualisierungen der Vollendung, so dass das Schreiben des zweiten neuen physikalischen Speicherortes 1020 beginnen kann.
10d zeigt einen Schritt, in dem ebenfalls das Schreiben der vollständig aktualisierten Kopie beendet ist, so dass ebenfalls die Statusanzeige derselben nach "transaktionsbeschrieben" geändert wird. 10e zeigt, wie die Statusanzeige der älteren teilweise aktualisierten Version nach "unrein" geändert wird, während die Transaktion noch nicht abgeschlossen bleibt. Der nächste Schritt ist das Abschließen der Transaktion durch Entfernen von TID#Y von dem Speicher der aktiven Transaktionsbezeichner (nicht gezeigt). Das Abschließen muss in einem Stadium durchgeführt werden, in dem lediglich eine aktualisierte Version der verbliebenen Daten in dem "Transaktionsbeschrieben"-Zustand ist, da mehrfach aktualisierte Versionen in dem Zustand beim nächsten Start, falls ein Systemfehler aufgetreten ist unmittelbar nach dem Abschließen, eine Zweideutigkeit verursachen würden. Der in 10f gezeigte letzte Schritt weist das Aktualisieren der Zustandsbezeichner auf, so dass der zweite neue physikalische Speicherort 1020 nun gültige Daten aufweist und die anderen physikalischen Speicherorte unrein sind.
Es gibt einige alternative Reihenfolgen, in denen die Statusanzeigen der physikalischen Speicherorte in dem Fall von verketteten Schreiboperationen geändert werden können. Beispielsweise kann der Zustand der teilweise aktualisierten Kopie bei dem ersten neuen physikalischen Speicherort 1010 nach "unrein" verändert werden, sogar bevor das Schreiben an den zweiten neuen physikalischen Speicherort 1020 beginnt. Mit anderen Worten, die Statusanzeigen in 10c würden von oben nach unten V, D und W und in allen weiteren Schritten würde der Zustand des ersten neuen physikalischen Speicherortes "unrein" bleiben. Eine andere Möglichkeit ist das Verändern des Zustands der teilweise aktualisierten Kopie bei dem ersten neuen physikalischen Speicherort 1010 nach "unrein" nachdem das Schreiben an den zweiten neuen physikalischen Speicherort 1020 begonnen hat, aber bevor der Zustand des letzteren von "beschrieben" nach "transaktionsbeschrieben" verändert wurde. Mit anderen Worten, der erste neue physikalische Speicherort wäre in den 10d, 10e und 10f "unrein".
Der vorher in Zusammenhang mit parallelen Transaktionen erläuterte allgemeine Ansatz kann verwendet werden zum Implementieren eines RAM-basierten Flash-Speicher-Schreib-Cache, welcher helfen würde, den Ansatz der verketteten Schreiboperationen zu rationalisieren. Dies bedeutet, dass eine Flash-Kopie eines bestimmten LDBD#X immer in das RAM schon dann gelesen wird, wenn eine Transaktion TID#X LDB#X das erste Mal aktualisiert und die teilweise aktualisierten Versionen werden lediglich in den Cache geschrieben. Daten werden von dem Flash-Speicher in den RAM-Puffer gelesen, sogar wenn es aktuell keine weiteren Transaktionen gibt, die den gleichen LDB aktualisieren. Wenn es weitere gleichzeitige Transaktionen gibt, die den LDB aktualisieren, wird das Verfahren der Abwicklung von parallelen Transaktionen direkt angewendet. Das Schreiben in den Cache, welches während der Ausführung einer Transaktion aber vor ihrer Abschließungsphase durchgeführt wird, ist unter dem Gesichtspunkt der Datenintegrität sicher. Es kann beachtlich die Leistungsfähigkeit eines Dateisystems verbessern, speziell wenn typische Aktualisierungen an einem LDB in dem Kontext einer Transaktion lediglich mit einem Bit oder Byte zu einer Zeit durchgeführt werden.
11 veranschaulicht in schematischer Weise eine Anordnung 1100 gemäß einer vorteilhaften Ausführungsform der Erfindung. Der Flash-Speicher 1101 ist mit einem Arbeitsraum-RAM 1102 über eine Lese-/Schreib-Einheit 1103 verknüpft, welche die tatsächliche Übertragung der Daten zwischen den beiden durchführt, und verwendet den Adressabbildungsblock 1104 zum Abbilden der Blockbezeichner der logischen Datenblockbezeichner in physikalische Speicherorte in dem Flash. Ein Programmausführungsblock 1105 steuert den Betrieb durch Ausführen der Befehle, die von einem Programmspeicher 1106 gelesen wurden, und/oder durch eine Eingabe-/Ausgabe-Schnittstelle 1107 erhalten wurden. Die Hintergrunds-Aufräumeinheit 1108 hält den Zustand des Flash-Speichers 1101 in einer als solchen bekannten Weise aufrecht.
Die beispielhaften Ausführungsformen der Erfindung, die oben diskutiert wurden, sollten nicht so interpretiert werden, dass sie der Anwendbarkeit der Erfindung ebenfalls in anderen Formen und alternativen Ausführungsformen, die als solche für den Fachmann im Lichte der vorstehenden Beschreibung offensichtlich sind und in den Umfang der beigefügten Ansprüche fallen, Beschränkungen auferlegt. Sogar wenn wir beispielsweise festgestellt haben, dass der Transaktionsbezeichner als solcher in dem Flash-Speicher zusammen mit dem aktualisierten LDB gespeichert wird, kann die gleiche Wirkung erzielt werden durch Speicherung eines anderen Wertes, der den aktualisierten LDB mit einem bestimmten Transaktionsbezeichner unzweideutig verknüpft, mit dem aktualisierten LDB.

Claims

Verfahren zum Aktualisieren eines ersten Blockes von digitalen Daten (601) mittels Durchführens einer Anzahl von Aktualisierungsoperationen, welche entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen, wobei die Anzahl größer oder gleich Eins ist, dadurch gekennzeichnet, dass es in der folgenden Reihenfolge die Schritte aufweist: – Aktivieren (701) eines ersten Bezeichners (TID), welcher all jenen Aktualisierungsoperationen gemeinsam ist, die sich auf den ersten Datenblock beziehen und entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen – Durchführen (703) all jener Aktualisierungsoperationen, die sich auf den ersten Datenblock beziehen und entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen – Speichern (707) des aktualisierten ersten Blocks der digitalen Daten in eine logische Flash-Speichervorrichtung (1101) zusammen mit einem Wert, der den aktualisierten ersten Datenblock mit dem ersten Bezeichner verknüpft und – Deaktivieren (710) des ersten Bezeichners.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Aktivierens (701) eines ersten Bezeichners den Unterschritt des Speicherns des ersten Bezeichners in einem nichtflüchtigen Speicherort (850), der für die Speicherung von aktiven Bezeichnern zugewiesen ist, aufweist.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Schritt des Aktivierens eines ersten Bezeichners die Unterschritte aufweist: a) Lesen (551) einer Kopie des Inhalts eines ersten nichtflüchtigen Speicherortes (501), der für die Speicherung von aktiven Bezeichnern zugewiesen ist, in einen Arbeitsspeicher (503) b) Ergänzen (552) der in den Arbeitsspeicher (503) gelesenen Kopie mit dem ersten Bezeichner (604), der aktiviert werden soll, so dass dadurch eine aktualisierte Kopie erzeugt wird c) Setzen (553) einer Statusanzeige (522) eines zweiten nichtflüchtigen Speicherortes (502) auf einen ersten Wert, der anzeigt, dass der Speicherort einem Schreibvorgang unterzogen wird d) Setzen (554) eines Datenblockbezeichners (521) in dem zweiten nichtflüchtigen Speicherort (502), so dass er gleich einem entsprechenden Datenblockbezeichner (511) in dem ersten nichtflüchtigen Speicherort (501) ist e) Schreiben (555) der aktualisierten Kopie in den zweiten nichtflüchtigen Speicherort (502) f) Setzen (556) der Statusanzeige (522) des zweiten nichtflüchtigen Speicherortes (502) auf einen zweiten Wert, der anzeigt, dass der Speicherort gültige Daten enthält g) Aktualisieren (557) einer Adressabbildungseinheit zum Verknüpfen des Datenblockbezeichners (521) in dem zweiten nichtflüchtigen Speicherort (502) mit der physikalischen Adresse des zweiten nichtflüchtigen Speicherortes (502) und h) Setzen einer Statusanzeige (512) des ersten nichtflüchtigen Speicherortes (501) auf einen dritten Wert, der anzeigt, dass der Speicherort ungültige Daten enthält.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der Unterschritt e) den Unter-Unterschritt des Schreibens, zusammen mit der aktualisierten Kopie, eines zyklischen Indikatorwertes in den zweiten nichtflüchtigen Speicherort (502) aufweist, wobei der zyklische Indikatorwert in dem ersten nichtflüchtigen Speicherort (501) ausgehend von einem entsprechenden zyklischen Indikatorwert um 1 erhöht wird.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Schritt des Deaktivierens (710) des ersten Bezeichners den Unterschritt des Löschens des ersten Bezeichners von dem nichtflüchtigen Speicherort (850) aufweist, der für die Speicherung der aktiven Bezeichner zugewiesen ist.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass der Schritt des Deaktivierens des ersten Bezeichners die Unterschritte aufweist: a) Lesen (551) einer Kopie des Inhalts eines zweiten nichtflüchtigen Speicherortes (502), der für die Speicherung von aktiven Bezeichnern zugewiesen ist, in einen Arbeitsspeicher (503) b) Löschen (552) des ersten Bezeichners, der deaktiviert werden soll, von der in den Arbeitsspeicher (503) gelesenen Kopie, um dadurch eine aktualisierte Kopie zu erzeugen c) Setzen (553) einer Statusanzeige eines dritten nichtflüchtigen Speicherortes auf einen ersten Wert, der anzeigt, dass der Speicherort einem Schreibvorgang unterzogen wird d) Setzen (554) eines Datenblockbezeichners in dem dritten nichtflüchtigen Speicherort dergestalt, dass er der gleiche ist wie ein entsprechender Datenblockbezeichner in dem zweiten nichtflüchtigen Speicherort (502) e) Schreiben (555) der aktualisierten Kopie in den dritten nichtflüchtigen Speicherort f) Setzen (556) der Statusanzeige des dritten nichtflüchtigen Speicherortes auf einen zweiten Wert, der anzeigt, dass der Speicherort gültige Daten enthält g) Aktualisieren (557) einer Adressabbildungseinheit zum Verknüpfen des Datenblockbezeichners in dem dritten nichtflüchtigen Speicherort mit der physikalischen Adresse des dritten nichtflüchtigen Speicherortes und h) Setzen (558) einer Statusanzeige des zweiten nichtflüchtigen Speicherortes (502) auf einen dritten Wert, der anzeigt, dass der Speicherort ungültige Daten enthält.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass der Unterschritt e) den Unter-Unterschritt des Schreibens, zusammen mit der aktualisierten Kopie, eines zyklischen Indikator wertes in den dritten nichtflüchtigen Speicherort aufweist, wobei der zyklische Indikatorwert in dem zweiten nichtflüchtigen Speicherort (502) von einem entsprechenden zyklischen Indikatorwert um Eins erhöht wird.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Schritt des Deaktivierens (710) des ersten Bezeichners den Unterschritt des Speicherns des ersten Bezeichners in einem Nichtflüchtigspeicher aufweist, welcher für die Speicherung von deaktivierten Bezeichnern zugewiesen ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Schritte des Durchführens der Aktualisierungsoperationen und des Speicherns des aktualisierten ersten Blockes von digitalen Daten die Unterschritte aufweisen: a) Lesen (702) einer Kopie des Inhalts eines ersten nichtflüchtigen Speicherortes, der für die Speicherung von zu aktualisierenden Daten zugewiesen ist, in einen Arbeitsspeicher b) Aktualisieren (703) der in den Arbeitsspeicher gelesenen Kopie, wodurch eine aktualisierte Kopie erzeugt wird c) Setzen (704) einer Statusanzeige eines zweiten nichtflüchtigen Speicherortes auf einen ersten Wert, der anzeigt, dass der Speicherort einem Schreibvorgang unterzogen wird d) Setzen (705) eines Datenblockbezeichners in dem zweiten nichtflüchtigen Speicherort so dass er der gleiche ist wie ein entsprechender Datenblockbezeichner in dem ersten nichtflüchtigen Speicherort e) Schreiben (706) des aktivierten ersten Bezeichners in den zweiten nichtflüchtigen Speicherort f) Schreiben (707) der aktualisierten Kopie in den zweiten nichtflüchtigen Speicherort g) Setzen (708) der Statusanzeige des zweiten nichtflüchtigen Speicherortes auf einen zweiten Wert, der anzeigt, dass der Speicherort Daten enthält, die aktualisiert wurden als ein Teil einer Anzahl von Aktualisierungsoperationen, die entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen und h) Überprüfen (709), ob alle der Anzahl von Aktualisierungsoperationen, welche entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen, durchgeführt wurden, und falls nicht, erneutes Beginnen bei Schritt a), so dass in den Schritten c), d), e), f) und g) ein unterschiedlicher zweiter nichtflüchtiger Speicherort betroffen ist.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass es zusätzlich die Unterschritte aufweist: i) Aktualisieren (711) einer Adressabbildungseinheit zum Verknüpfen jedes Datenblockbezeichners in einem nichtflüchtigen Speicherort, der eine gespeicherte aktualisierte Kopie enthält, mit der physikalischen Adresse des nichtflüchtigen Speicherortes j) Setzen (712) einer Statusanzeige jedes solchen nichtflüchtigen Speicherortes, die Gegenstand eines Unterschrittes a) war, auf einen dritten Wert, der anzeigt, dass der Speicherort ungültige Daten enthält k) Setzen (713) der Statusanzeige jedes zweiten nichtflüchtigen Speicherortes auf einen vierten Wert, der anzeigt, dass der Speicherort gültige Daten enthält.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zwischen den Schritten des Aktivierens (701) eines ersten Bezeichners, der allen jenen Aktualisierungsoperationen gemeinsam ist, die entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen, und des Deaktivierens (710) des ersten Bezeichners es zusätzlich die Schritte aufweist: – Durchführen (703) solcher Aktualisierungsoperationen, die andere Datenblöcke betreffen als den ersten Datenblock und entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen mit den Aktualisierungsoperationen des ersten Datenblocks und – Speichern (707) jedes aktualisierten Blocks von digitalen Daten in einer logischen Flash-Speichervorrichtung zusammen mit einem Wert, der jeden aktualisierten Datenblock mit dem ersten Bezeichner verknüpft.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Durchführens all jener Aktualisierungsoperationen, die den ersten Datenblock betreffen und entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen, den Unterschritt des Auswählens eines ersten Teils (A1) des ersten Datenblocks als das Ziel jener Aktualisierungsoperationen, welche auf den ersten Bezeichner (TID#A) bezogen sind, aufweist.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass es zusätzlich die Schritte aufweist: – Aktivieren eines zweiten Bezeichners (TID#B), welcher einer Anzahl von Aktualisierungsoperationen gemeinsam ist, die sich auf den ersten Datenblock (800) beziehen und alle zusammen entweder erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen, bei denen es aber nicht erforderlich ist, dass sie zusammen mit den Aktualisierungsoperationen, die mit dem ersten Bezeichner (TID#A) verknüpft sind, erfolgreich verlaufen oder fehlschlagen – Auswählen eines zweiten Teils (B1) des ersten Datenblocks als das Ziel jener Aktualisierungsoperationen, die sich auf den zweiten Bezeichner (TID#B) beziehen, wobei der zweite Teil nicht mit dem ersten Teil (A1) überlappt – Durchführen all jener Aktualisierungsoperationen, die sich auf den ersten Datenblock beziehen, mit dem zweiten Bezeichner (TID#B) verknüpft sind und entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen – Übertragen der aktualisierten Ergebnisse (A2) jener Aktualisierungsoperationen, die mit einem der Bezeichner (TID#A) verknüpft sind und abgeschlossen werden vor den Aktualisierungsoperationen, die mit dem anderen der Bezeichner (TID#B) verknüpft sind, an der Kopie des Datenblocks, auf dem durch die Aktualisierungsoperationen, die mit dem anderen der Bezeichner verknüpft sind, gearbeitet wird – Speichern des aktualisierten ersten Blockes von digitalen Daten in eine logische Flash-Speichervorrichtung zusammen mit einem Wert, der den aktualisierten ersten Datenblock mit dem zweiten Bezeichner (TID#B) verknüpft und – Deaktivieren des zweiten Bezeichners (TID#B).
Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Schritte des Speicherns des aktualisierten ersten Blocks von digitalen Daten in eine logische Flash-Speichervorrichtung zusammen mit einem Wert, der den aktualisierten ersten Datenblock mit dem ersten Bezeichner (TID#A) verknüpft, und des Speicherns des aktualisierten ersten Blocks von digitalen Daten in eine logische Flash-Speichervorrichtung zusammen mit einem Wert, der den aktualisierten ersten Datenblock mit dem zweiten Bezeichner (TID#B) verknüpft, die Unterschritte aufweisen: a) Setzen einer Statusanzeige eines ersten nichtflüchtigen Speicherortes (810) auf einen ersten Wert (W), der anzeigt, dass der Speicherort einem Schreibvorgang unterzogen wird b) Schreiben der aktualisierten Kopie, die erzeugt wird durch jene Aktualisierungsoperationen, die mit einem der Bezeichner (TID#A) verknüpft sind und abgeschlossen werden vor den Aktualisierungsoperationen, die mit dem anderen der Bezeichner (TID#B) verknüpft sind, in den ersten nichtflüchtigen Speicherort (810), c) Schreiben von ebenfalls dem Bezeichner (TID#A), der mit den Aktualisierungsoperationen verknüpft ist, die die aktualisierte Kopie erzeugen, welche im Unterschritt b) geschrieben wird, in den ersten nichtflüchtigen Speicherort (810) d) Setzen der Statusanzeige des ersten nichtflüchtigen Speicherortes (810) auf einen zweiten Wert (T), der anzeigt, dass der Speicherort Daten enthält, die aktualisiert wurden als ein Teil einer Anzahl von Aktualisierungsoperationen, welche entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen e) Deaktivieren des Bezeichners (TID#A), der mit den Aktualisierungsoperationen verknüpft ist, die die aktualisierte Kopie erzeugten, welche im Unterschritt b) geschrieben wurde f) Setzen einer Statusanzeige des nichtflüchtigen Speicherortes (800), von der der Datenblock genommen wurde, um ein Gegenstand der Aktualisierung zu sein, auf einen dritten Wert (D), der anzeigt, dass der Speicherort ungültige Daten enthält g) Setzen der Statusanzeige des ersten nichtflüchtigen Speicherortes (810) auf einen vierten Wert (V), der anzeigt, dass der Speicherort gültige Daten enthält h) Setzen einer Statusanzeige eines zweiten nichtflüchtigen Speicherortes (820) auf einen ersten Wert (W), der anzeigt, dass der Speicherort einem Schreibvorgang unterzogen wird i) Schreiben der aktualisierten Kopie, die erzeugt wird durch jene Aktualisierungsoperationen, die mit dem verbleibenden aktiven der Bezeichner (TID#B) verknüpft sind, erzeugt wird, in den zweiten nichtflüchtigen Speicherort (820), j) Schreiben von ebenfalls dem Bezeichner (TID#B), der mit den Aktualisierungsoperationen verknüpft ist, die die aktualisierte Kopie erzeugten, die beim Unterschritt i) geschrieben wird, in den zweiten nichtflüchtigen Speicherort (820) k) Setzen der Statusanzeige des zweiten nichtflüchtigen Speicherortes (820) auf einen zweiten Wert (T), der anzeigt, dass der Speicherort Daten enthält, die aktualisiert wurden als ein Teil einer Anzahl von Aktualisierungsoperationen, die entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen l) Deaktivieren des Bezeichners (TID#B), der mit den Aktualisierungsoperationen verknüpft ist, die die aktualisierte Kopie erzeugt haben, welche beim Unterschritt i) geschrieben wurde m) Setzen der Statusanzeige des ersten nichtflüchtigen Speicherortes (810) auf einen dritten Wert (D), der anzeigt, dass der Speicherort ungültige Daten enthält, und n) Setzen der Statusanzeige des zweiten nichtflüchtigen Speicherortes (820) auf einen vierten Wert (V), der anzeigt, dass der Speicherort gültige Daten enthält.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zum Wiederherstellen von einem Systemfehler in einem Dateisystem basierend auf einer logischen Flash-Speichervorrichtung es die Schritte aufweist: – Überprüfen anhand einer Liste (850) von aktiven Bezeichnern, welche Bezeichner im Moment des Auftretens des Systemfehlers aktiv waren und – Überprüfen der physikalischen Speicherorte zum Lokalisieren von Datenblöcken, die einen Wert enthalten, der sie mit einem Bezeichner verknüpft, welcher zu dem Zeitpunkt des Auftretens des Systemfehlers aktiv war, und Setzen einer Statusanzeige eines jeden solchen nichtflüchtigen Speicherortes, der solch einen Datenblock enthält, auf einen Wert, der anzeigt, dass der Speicherort ungültige Daten enthält.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass es zusätzlich die Schritte aufweist: – Überprüfen der physikalischen Speicherplätze zum Lokalisieren von Paaren von Datenblöcken, wobei – der gleiche Datenblockbezeichner (602) in jedem Datenblock innerhalb des Paares erscheint, – keiner der Datenblöcke innerhalb des Paares mit einem Bezeichner verknüpft ist, der zu dem Zeitpunkt des Auftretens des Systemfehlers aktiv war – ein erster Datenblock innerhalb des Paares an einem Speicherort gespeichert ist mit einem Statusanzeiger (603), der anzeigt, dass der Speicherort gültige Daten enthält, und – ein zweiter Datenblock innerhalb des Paares in einem Speicherort gespeichert ist mit einem Statusanzeiger (603), der anzeigt, dass der Speicherort Daten enthält, die aktualisiert wurden als ein Teil einer Anzahl von Aktualisierungsoperationen, die entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen, – Setzen eines Statusanzeigers (603) jedes solchen nichtflüchtigen Speicherortes, der einen ersten Datenblock innerhalb eines Paares enthält, auf einen Wert (D), der anzeigt, dass der Speicherort ungültige Daten enthält, und – Setzen einer Statusanzeige (603) jedes solchen nichtflüchtigen Speicherortes, der einen zweiten Datenblock innerhalb eines Paares enthält, auf einen Wert (V), der anzeigt, dass der Speicherort gültige Daten enthält.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass es zusätzlich die Schritte aufweist: – Überprüfen der physikalischen Speicherplätze zum Lokalisieren von Datenblöcken, welche – nicht mit einem Bezeichner verknüpft sind, der zu dem Zeitpunkt des Auftretens des Systemfehlers aktiv war, und – in einem Speicherort mit einer Statusanzeige (603) gespeichert sind, welche anzeigt, dass der Speicherort Daten enthält, die aktualisiert wurden als ein Teil einer Anzahl von Aktualisierungsoperationen, welche entweder alle erfolgreich verlaufen müssen oder alle fehlschlagen müssen; und – Setzen einer Statusanzeige (603) jedes solchen nichtflüchtigen Speicherortes, der solch einen Datenblock enthält, auf einen Wert (V), der anzeigt, dass der Speicherort gültige Daten enthält.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass der Schritt des Überprüfens einer Liste von aktiven Bezeichnern (850), wobei die Bezeichner aktiv zu dem Zeitpunkt des Auftretens des Systemfehlers waren, die Unterschritte aufweist: a) Lokalisieren aller nichtflüchtigen Speicherplätze in der logischen Flash-Speichervorrichtung, die eine Liste von aktiven Bezeichnern enthalten und eine Statusanzeige, die anzeigt, dass der Speicherort gültige Daten enthält b) in dem Fall von lediglich einem nichtflüchtigen Speicherort dieser Art, der bei Unterschritt a) lokalisiert wurde, Auswählen der Liste von aktiven Bezeichnern, die darin enthalten ist als die gültige Liste von aktiven Bezeichnern und c) in dem Fall von mehr als einem nichtflüchtigen Speicherort der Art, der bei Unterschritt a) lokalisiert wurde, Auswählen der Liste von aktiven Bezeichnern, die in einem der lokalisierten nichtflüchtigen Speicherplätze enthalten sind, als die gültige Liste von aktiven Bezeichnern.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass der Unterschritt c) die Unter-Unterschritte enthält: c1) Lesen des Wertes eines zyklischen Indikators von jedem lokalisierten nichtflüchtigen Speicherort und c2) Auswählen der Liste von aktiven Bezeichnern, die in dem lokalisierten nichtflüchtigen Speicherort enthalten ist, als die gültige Liste von aktiven Bezeichnern, die mit dem höchsten zyklischen Indikatorwert verknüpft ist.
Anordnung (1100) zum Aktualisieren eines ersten Blockes von digitalen Daten mittels Durchführens einer Anzahl von Aktualisierungsoperationen, welche entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen, wobei die Anzahl größer oder gleich Eins ist, dadurch gekennzeichnet, dass sie aufweist: – eine logische Flash-Speichervorrichtung (1101) – Mittel (1102, 1103, 1104, 1105) zum Aktivieren eines ersten Bezeichners, der all jenen Aktualisierungsoperationen gemeinsam ist, die sich auf den ersten Datenblock beziehen und entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen – Mittel (1102, 1103, 1104, 1105) zum Durchführen all jener Aktualisierungsoperationen, die sich auf den ersten Datenblock beziehen und entweder alle zusammen erfolgreich verlaufen müssen oder alle zusammen fehlschlagen müssen – Mittel (1102, 1103, 1104, 1105) zum Speichern des aktualisierten ersten Blockes der digitalen Daten in der logischen Flash-Speichervorrichtung (1101) zusammen mit einem Wert, der den aktualisierten Datenblock mit dem ersten Bezeichner verknüpft, und – Mittel (1102, 1103, 1104, 1105) zum Deaktivieren des ersten Bezeichners.
Anordnung nach Anspruch 20, dadurch gekennzeichnet, dass die logische Flash-Speichervorrichtung (1101) aus mindestens zwei physikalisch getrennten Speichervorrichtungen besteht, welche zusammen eine logisch ganze Speichervorrichtung bilden.
Anordnung nach Anspruch 21, dadurch gekennzeichnet, dass die zumindest zwei physikalisch getrennten Speichervorrichtungen einen Festkörper-Flash-Speicher und ein Magnetplattenlaufwerk aufweisen.