DE112019000849T5 - Hostorientierter Aktualisierungsschreibvorgang - Google Patents

Hostorientierter Aktualisierungsschreibvorgang Download PDF

Info

Publication number
DE112019000849T5
DE112019000849T5 DE112019000849.8T DE112019000849T DE112019000849T5 DE 112019000849 T5 DE112019000849 T5 DE 112019000849T5 DE 112019000849 T DE112019000849 T DE 112019000849T DE 112019000849 T5 DE112019000849 T5 DE 112019000849T5
Authority
DE
Germany
Prior art keywords
data
logical address
unit
older
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112019000849.8T
Other languages
English (en)
Inventor
Steven Robert Hetzler
Robert Michael Rees
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112019000849T5 publication Critical patent/DE112019000849T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0656—Data buffering arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/0679—Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1032—Reliability improvement, data loss prevention, degraded operation etc
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7201—Logical to physical mapping or translation of blocks or pages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7203—Temporary buffering, e.g. using volatile buffer or dedicated buffer blocks

Abstract

Eine einzelne Ausführungsform stellt ein Verfahren bereit, welches das Verwalten, auf einer Speichereinheit, von Zuordnungsdaten zwischen einem ersten Satz von logischen Adressen (z.B. logischen Blockadressen oder LBAs), die von einem Host betrachtet werden, und einem ersten Satz von physischen Adressen (z.B. physischen Blockadressen oder PBAs) sowie einem zweiten Satz von physischen Adressen der Speichereinheit umfasst. Eine erste logische Adresse (z.B. LBA) des ersten Satzes von logischen Adressen entspricht einer ersten physischen Adresse (z.B. PBA) des ersten Satzes von physischen Adressen, die aktuelle Daten für die erste logische Adresse verwaltet. Die erste logische Adresse entspricht des Weiteren einer zweiten physischen Adresse (z.B. PBA) des zweiten Satzes von physischen Adressen, die ältere Daten für die erste logische Adresse verwaltet. Das Verfahren umfasst des Weiteren das Empfangen, an der Speichereinheit, eines Befehls von dem Host zum Durchführen einer Multi-Device-Operation, an der die erste logische Adresse beteiligt ist. Die Operation wird atomar durchgeführt.

Description

  • Die vorliegende Erfindung betrifft allgemein Speichersysteme und insbesondere ein System und ein Verfahren, um ein hostorientiertes Aktualisierungsschreibvorgang-Protokoll auszuführen.
  • HINTERGRUND
  • Hardwarebasierte Speichersysteme stellen üblicherweise einen getrennten nicht flüchtigen Speicher zum Schutz von Daten gegen unbeabsichtigten Stromausfall bereit. Eine typische Verwendung für diesen getrennten nicht flüchtigen Speicher ist die Ausführung eines Write-ahead-Protokolls, das gewährleistet, dass fehlende Aktualisierungen für die atomaren Read-modify-write-Operationen angewendet werden können, die zu der Löschcodierung gehören. Im Vergleich dazu können softwaredefinierte Speichersysteme, die eine Löschcodierung zum Datenschutz ausführen, nicht vom Vorhandensein eines nicht flüchtigen Speichers ausgehen und sind daher gezwungen, diese Write-ahead-Protokolle unter Verwendung von zusätzlichen Speichereinheiten auszuführen, was die E/A-Last auf der Systemebene erhöht, wobei dies zu einem verringerten Durchsatz und einer längeren Antwortzeit führt.
  • KURZDARSTELLUNG
  • Eine einzelne Ausführungsform stellt ein Verfahren bereit, welches das Verwalten, auf einer Speichereinheit, von Zuordnungsdaten zwischen einem ersten Satz von logischen Adressen (z.B. logischen Blockadressen oder LBAs), die von einem Host betrachtet werden, und einem ersten Satz von physischen Adressen (z.B. physischen Blockadressen oder PBAs) sowie einem zweiten Satz von physischen Adressen der Speichereinheit umfasst. Eine erste logische Adresse (z.B. LBA) des ersten Satzes von logischen Adressen entspricht einer ersten physischen Adresse (z.B. PBA) des ersten Satzes von physischen Adressen, die aktuelle Daten für die erste logische Adresse verwaltet. Die erste logische Adresse entspricht des Weiteren einer zweiten physischen Adresse (z.B. PBA) des zweiten Satzes von physischen Adressen, die ältere Daten für die erste logische Adresse verwaltet. Das Verfahren umfasst des Weiteren das Empfangen, an der Speichereinheit, eines Befehls von dem Host zum Durchführen einer Multi-Device-Operation, an der die erste logische Adresse beteiligt ist. Die Operation wird atomar durchgeführt.
  • Diese und andere Aspekte, Merkmale und Vorteile der Erfindung lassen sich unter Bezugnahme auf die Zeichnungsfiguren und die detaillierte Beschreibung hierin verstehen und werden mittels der verschiedenen Elemente und Kombinationen, die in den beigefügten Ansprüchen genauer dargelegt sind, realisiert. Es sollte darauf hingewiesen werden, dass sowohl die vorstehende allgemeine Beschreibung als auch die folgende kurze Beschreibung der Zeichnungen und die ausführliche Beschreibung der Erfindung beispielhaft und erklärend für bevorzugte Ausführungsformen der Erfindung sind und die Erfindung, wie beansprucht, nicht einschränken.
  • Figurenliste
  • Der als die Erfindung betrachtete Gegenstand ist in den Ansprüchen am Ende der Beschreibung genauer dargelegt und gesondert beansprucht. Die vorstehenden und weitere Aufgaben, Merkmale und Vorteile der Erfindung gehen aus der folgenden ausführlichen Beschreibung in Zusammenschau mit den beiliegenden Zeichnungen hervor, bei denen:
    • 1A ein herkömmliches softwaredefiniertes löschcodiertes Speichersystem in einem Anfangszustand zum Zeitpunkt t0 veranschaulicht;
    • 1B das Speichersystem zum Zeitpunkt t1 veranschaulicht;
    • 1C das Speichersystem zum Zeitpunkt t2 veranschaulicht;
    • 1D das Speichersystem zum Zeitpunkt t3 veranschaulicht;
    • 1E das Speichersystem zum Zeitpunkt t4veranschaulicht;
    • 1F das Speichersystem zum Zeitpunkt t5veranschaulicht;
    • 2A ein beispielhaftes Framework für Speicher in einer oder mehreren Ausführungsformen veranschaulicht;
    • 2B ein weiteres beispielhaftes Framework für Speicher in einer oder mehreren Ausführungsformen veranschaulicht;
    • 2C noch ein weiteres beispielhaftes Framework für Speicher in einer oder mehreren Ausführungsformen veranschaulicht;
    • 3 ein Ablaufplan ist, der einen beispielhaften Prozess zum Ausführen eines hostorientierten Aktualisierungsprotokolls, damit ein Einzelparitäts-Löschcode intakt bleibt, in einer oder mehreren Ausführungsformen veranschaulicht; und
    • 4 ein Übersichtsblockschaltbild ist, das ein Informationsverarbeitungssystem zeigt, welches zur Ausführung einer Ausführungsform der vorliegenden Erfindung nützlich ist.
  • Die ausführliche Beschreibung erklärt die bevorzugten Ausführungsformen der Erfindung zusammen mit Vorteilen und Merkmalen anhand eines Beispiels unter Bezugnahme auf die Zeichnungen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die vorliegende Erfindung betrifft allgemein Speichersysteme und insbesondere ein System und ein Verfahren, um ein hostorientiertes Aktualisierungsschreibvorgang-Protokoll auszuführen. Eine einzelne Ausführungsform stellt ein Verfahren bereit, welches das Verwalten, auf einer Speichereinheit, von Zuordnungsdaten zwischen einem ersten Satz von logischen Adressen (z.B. logischen Blockadressen oder LBAs), die von einem Host betrachtet werden, und einem ersten Satz von physischen Adressen (z.B. physischen Blockadressen oder PBAs) sowie einem zweiten Satz von physischen Adressen der Speichereinheit umfasst. Eine erste logische Adresse (z.B. LBA) des ersten Satzes von logischen Adressen entspricht einer ersten physischen Adresse (z.B. PBA) des ersten Satzes von physischen Adressen, die aktuelle Daten für die erste logische Adresse verwaltet. Die erste logische Adresse entspricht des Weiteren einer zweiten physischen Adresse (z.B. PBA) des zweiten Satzes von physischen Adressen, die ältere Daten für die erste logische Adresse verwaltet. Das Verfahren umfasst des Weiteren das Empfangen, an der Speichereinheit, eines Befehls von dem Host zum Durchführen einer Multi-Device-Operation, an der die erste logische Adresse beteiligt ist. Die Operation wird atomar durchgeführt.
  • Für Erklärungszwecke bezieht sich der Begriff „löschcodiertes Speichersystem“ in der Verwendung hierin allgemein auf ein Speichersystem, das eine allgemeine Klasse von Algorithmen für Datenausfallsicherheit ausführt, wie beispielsweise, ohne darauf beschränkt zu sein, auf Speichersysteme, die eine beliebige Ebene eines Redundant Array of Independent Disks (RAID) ausführen.
  • Herkömmliche softwaredefinierte Speichersysteme, die Löschcodierung zum Datenschutz ausführen, können nicht vom Vorhandensein von nicht flüchtigem Speicher ausgehen. Die 1A bis 1F veranschaulichen eine beispielhafte Abfolge von Schritten zum Durchführen einer Aktualisierungsschreiboperation auf einem herkömmlichen softwaredefinierten löschcodierten Speichersystem 10.
  • 1A veranschaulicht das Speichersystem 10 in einem Anfangszustand zum Zeitpunkt t0. Das Speichersystem 10 führt einen 3+P-Löschcode zum Datenschutz aus. Das Speichersystem 10 weist eine oder mehrere nicht flüchtige Speichereinheiten 12 zum Verwalten von Daten (z.B. Datenblöcken und Paritätsblöcken) auf. Das Speichersystem 10 weist des Weiteren einen flüchtigen Pufferspeicher 11 auf, um Daten während Eingabe-/Ausgabe-(E/A-)Operationen auf der einen oder den mehreren Speichereinheiten 12 zu halten. Wie in 1A gezeigt ist, verwalten die eine oder mehreren Speichereinheiten 12 im Anfangszustand den Datenblock D0, den Datenblock D1, den Datenblock D2 und einen Paritätsblock DP, der gemäß der nachstehend bereitgestellten Paritätsgleichung (1) berechnet wird: DP = D0 + D1 + D2
    Figure DE112019000849T5_0001
    wobei + eine Exklusiv-ODER-(XOR-)Operation bezeichnet.
  • Ein Paritätsstripe weist einen Satz von Datenblöcken und einen oder mehrere Paritätsblöcke auf, die dem Satz von Datenblöcken entsprechen. Zum Beispiel bilden die Datenblöcke D0 bis D2 und der Paritätsblock DP zusammen ein Paritätsstripe.
  • 1B veranschaulicht das Speichersystem 10 zum Zeitpunkt t1. Nehmen wir an, dass die Aktualisierungsschreiboperation eine von einem externen Hostsystem ausgegebene Multi-Device-Operation ist und einen Aktualisierungsschreibvorgang des Datenblocks D0 in der einen oder den mehreren Speichereinheiten 12 mit dem neuen Datenblock D0' erfordert. Zum Zeitpunkt t1 liest das Speichersystem 10, als Reaktion auf den Empfang der Aktualisierungsschreiboperation von dem externen Hostsystem, den Datenblock D0 aus der einen oder den mehreren Speichereinheiten 12 in den flüchtigen Pufferspeicher 11.
  • 1C veranschaulicht das Speichersystem 10 zum Zeitpunkt t2. Um die Aktualisierungsschreiboperation erfolgreich abzuschließen, muss der Paritätsblock DP ebenfalls auf den neuen Paritätsblock DP‘ aktualisiert werden. Zum Zeitpunkt t2 liest das Speichersystem 10 den Paritätsblock DP aus der einen oder den mehreren Speichereinheiten 12 in den flüchtigen Pufferspeicher 110.
  • 1D veranschaulicht das Speichersystem 10 zum Zeitpunkt t3. Zum Zeitpunkt t3 berechnet das Speichersystem 10 den neuen Paritätsblock DP‘ gemäß der nachstehend bereitgestellten Paritätsgleichung (2): DP ' = D0 + D0 ' + DP
    Figure DE112019000849T5_0002
  • 1E veranschaulicht das Speichersystem 10 zum Zeitpunkt t4. Zum Zeitpunkt t4 schreibt das Speichersystem 10 den neuen Datenblock D0' in die eine oder die mehreren Speichereinheiten 120.
  • 1F veranschaulicht das Speichersystem 10 zum Zeitpunkt t5. Zum Zeitpunkt t5 schreibt das Speichersystem 10 den neuen Paritätsblock DP‘ in die eine oder die mehreren Speichereinheiten 120, um die Aktualisierungsschreiboperation abzuschließen.
  • Die Schritte, die den Datenblock D0 und das Paritätsstripe DP einschließen, sind asynchron, so dass die in den 1A bis 1F veranschaulichte Abfolge von Schritten eine mögliche Reihenfolge ist.
  • Wenn zwischen dem Zeitpunkt t4 und dem Zeitpunkt t5 ein unbeabsichtigtes Stromausfallereignis eintritt, hat dies eine Gefährdung der Datenintegrität zur Folge. Genauer gesagt, der Paritätsblock DP kann beeinträchtigt werden, was zu einem unbestimmten Paritätszustand führt, aus dem das Speichersystem 10 nicht wiederhergestellt werden kann. Der unbestimmte Paritätszustand für den Paritätsblock DP kann gemäß dem nachstehend bereitgestellten Ausdruck (3) ausgedrückt werden: DP ! = D0 ' + D1 + D2
    Figure DE112019000849T5_0003
  • Wenn das externe Hostsystem die Aktualisierungsschreiboperation wiederholen würde, würde das Speichersystem 10 einen ungültigen neuen Paritätsblock DP‘ bereitstellen, da das Speichersystem 10 den neuen Paritätsblock DP‘ gemäß der nachstehend bereitgestellten Paritätsgleichung (4) berechnen würde: DP ' = D0 ' + D0 ' + DP
    Figure DE112019000849T5_0004
    wobei die Paritätsgleichung (4) aufgrund der Eigenschaften der XOR-Operation auf die nachstehend bereitgestellte Paritätsgleichung (5) vereinfacht wird: DP ' = DP
    Figure DE112019000849T5_0005
  • Wenn die zu den Zeitpunkten t4 und t5 durchgeführten Schritte umgekehrt würden, hat dies im Falle eines Stromausfalls ähnliche Gefährdungen der Datenintegrität zur Folge. Des Weiteren ist das Potenzial für Gefährdungen der Datenintegrität größer, wenn ein Paritätsblock mittels einer komplexeren Paritätsgleichung ausgedrückt wird. Somit besteht eine Notwendigkeit für eine permanente Speicherung einer Aktualisierungsschreiboperation und dafür, dass diese Multi-Device-Operation atomar ist.
  • Es ist wünschenswert, dass softwaredefinierte Systeme über Eigenschaften verfügen, die für eine Wiederherstellung nach Ereignissen wie beispielsweise einem Stromausfall notwendig sind, wie Atomizität sowie andere Eigenschaften in Verbindung mit Dauerhaftigkeit. Wenn zum Beispiel ein unbeabsichtigter Stromausfall während einer Aktualisierungsschreiboperation eintritt, muss ein softwaredefiniertes Speichersystem in der Lage sein, einen konsistenten Speicherzustand wiederherzustellen und einen korrekten Löschcode sicherzustellen.
  • Bei einem herkömmlichen softwaredefinierten Speichersystem ohne einen nicht flüchtigen Pufferspeicher werden Protokolle verwendet, um Atomizität für Datenaktualisierungen auszuführen. Protokolle werden üblicherweise in zusätzlichen nicht flüchtigen Speichereinheiten eines Speichersystems gespeichert. Eine Replikation kann zum Datenschutz der Protokolle ausgeführt werden, um Gefährdungen der Datenintegrität zu vermeiden, die die Folge im Falle eines Stromausfalls sind.
  • Ein herkömmliches Verfahren zum Ausführen von Atomizität für Datenaktualisierungen stellt die Write-ahead-Protokollierung (d.h. Schattenprotokollierung) dar, bei der ein Write-ahead-Transaktionsprotokoll verwendet wird, wenn ein Paritätsblock aktualisiert wird. Die Write-ahead-Protokollierung geht mit einem hohen E/A-Verstärkungsnachteil einher.
  • Zum Beispiel sei d1', d2', ..., dN‘ ein Satz von N logischen Adressen (z.B. logischen Blockadressen oder LBAs) für neue Datenblöcke, die einen atomaren Aktualisierungsschreibvorgang (d.h. einen über die nicht flüchtigen Speichereinheiten atomar erfolgenden Aktualisierungsschreibvorgang) erforderlich machen. Es sei p1', p2', ..., pM‘ ein Satz von M LBAs für neue Paritätsblöcke, die den N LBAs entsprechen und die ebenfalls einen atomaren Aktualisierungsschreibvorgang erforderlich machen. Es seien d1, d2, ..., dN und p1, p2, ..., pM ältere Versionen der N LBAs bzw. der M LBAs.
  • Um einen Paritätsblock mittels eines Aktualisierungsschreibvorgangs zu aktualisieren, sind Leseoperationen notwendig, die das Lesen der älteren Versionen der N LBAs und der M LBAs (d.h. d1, d2, ..., dN und p1, p2, ..., pM) aus den nicht flüchtigen Speichereinheiten einschließen, so dass die M LBAs mittels einer Paritätsgleichung aus den N LBAs berechnet werden können. Diese Leseoperationen erfordern N + M Blocklesevorgänge.
  • Um Atomizität für die Aktualisierungsschreibvorgänge zu erreichen, wird ein Multiblock-Protokollsatz geschrieben, bevor neue Datenblöcke und neue Paritätsblöcke in die nicht flüchtigen Speichereinheiten geschrieben werden. Der Protokollsatz weist die neuen Datenblöcke und die neuen Paritätsblöcke auf (d.h. d2', ..., dN‘ und p1', p2', ..., pM‘). Der Protokollsatz kann die neuen Daten und Paritätswerte integriert als Teil des Protokollsatzes selbst enthalten oder er kann Zeiger auf Blöcke enthalten, die aus einem von der Implementierung verwalteten Schattenblockbereich zugeordnet werden. In beiden Fällen sind N + M Blockschreibvorgänge in den Protokollsatz und/oder den Schattenblockbereich erforderlich. Des Weiteren sind C Spiegelkopien des Protokollsatzes erforderlich, um den Protokollsatz selbst vor Datenverlust zu schützen, wobei C ein Wert ist, der so ausgewählt wird, dass er der Fehlertoleranz eines von dem Speichersystem ausgeführten Löschcodes entspricht. Folglich führt eine Write-ahead-Protokollierung zu einem Schreibvorgang-Verstärkungsfaktor von C(N + M) Schreibvorgängen.
  • Erst wenn die neuen Datenblöcke und Paritätsblöcke sicher in den Protokollsatz geschrieben sind, können die neuen Datenblöcke und Paritätsblöcke in die nicht flüchtigen Speichereinheiten geschrieben werden. Daher ist der gesamte E/A-Verstärkungsfaktor für die atomaren Aktualisierungsschreibvorgänge bei Verwendung einer Write-ahead-Protokollierung die Summe aus N + M Blocklesevorgängen und C(N + M) Schreibvorgängen.
  • Da Datenblöcke und Paritätsblöcke nicht synchronisiert werden, kann ein Paritätsblock beeinträchtigt werden (d.h. unbestimmter Paritätszustand).
  • Eine einzelne Ausführungsform stellt ein System und ein Verfahren für eine Schreibvorgangsreduktion (d.h. eine Verringerung der Schreib-E/A-Last) auf Speichersystemen unter Verwendung von Schattenprotokollen in Verbindung mit einem Write-ahead-Transaktionsprotokoll bereit, um die Datenintegrität durch Atomizität zu wahren, wenn zugrunde liegender Speicher eine Kopieren-beim-Schreiben-(Copy-on-write-(COW-))Methode verwendet. Ohne einen solchen Datenschutz kann es bei einem unbeabsichtigten Stromausfall zu einer Gefährdung der Datenintegrität kommen. Eine einzelne Ausführungsform gilt für Flashspeicher und COW-Dateisysteme wie beispielsweise ZFS. Eine einzelne Ausführungsform vermeidet zusätzliche Schreiboperationen, die üblicherweise erforderlich sind, um Ausfallsicherheit für Schattenkopien und Write-ahead-Transaktionsprotokolle bereitzustellen.
  • Eine COW-Speichereinheit, wie etwa Flash, verfügt über eine interne Umsetzungsschicht, die Metadaten-Informationen verwaltet, um einen Satz von logischen Adressen (z.B. LBAs), die ein externes Hostsystem sieht, einem Satz von physischen Adressen (z.B. physischen Blockadressen oder PBAs) der Speichereinheit zuzuordnen („Zuordnungsdaten“). Da ein Flashspeicher im Allgemeinen keine sofortige Aktualisierung für Schreiboperationen unterstützt, ermöglicht eine interne Verwaltung der Zuordnungsdaten der Speichereinheit, Garbage-Collection von ganzen Löschblöcken zu unterstützen.
  • 2A veranschaulicht ein beispielhaftes Framework 50 für Speicher in einer oder mehreren Ausführungsformen. Das beispielhafte Framework 50 weist ein softwaredefiniertes Speichersystem 100 und ein mit dem Speichersystem 100 verbundenes externes Hostsystem 60 auf.
  • In einer einzelnen Ausführungsform ist das Speichersystem 100 ein Speicherarray, das eine oder mehrere nicht flüchtige Speichereinheiten 120 (z.B. COW-Speichereinheiten) zum Verwalten von Daten (z.B. Datenblöcken und Paritätsblöcken) aufweist. Das Speichersystem 100 weist des Weiteren eine E/A-Einheit 130 auf, die so konfiguriert ist, dass sie Daten mit dem Hostsystem 60 austauscht, beispielsweise Befehle (z.B. Lesebefehle, Schreibbefehle usw.) empfängt. Das Speichersystem 100 weist des Weiteren einen flüchtigen Pufferspeicher 110 auf, um Daten während E/A-Operationen zu halten, die als Reaktion auf die empfangenen Befehle auf der einen oder den mehreren Speichereinheiten 120 durchgeführt werden. In einer einzelnen Ausführungsform führt das Speichersystem 100 einen Löschcode zum Datenschutz aus (d.h. ein löschcodiertes Speichersystem).
  • In einer einzelnen Ausführungsform betrachtet das Hostsystem 60 Daten, die auf der einen oder den mehreren Speichereinheiten 120 gespeichert sind, als einen virtualisierten Adressraum von LBAs, ohne dass es Kenntnis von Begrenzungen der einen oder der mehreren Speichereinheiten 120 oder von Einzelheiten des von dem Speichersystem 100 ausgeführten Löschcodes hat. Das Hostsystem 60 weist eine E/A-Einheit 61 auf, die so konfiguriert ist, dass sie Daten mit dem Speichersystem 100 austauscht, beispielsweise Befehle (z.B. Lesebefehle, Schreibbefehle usw.) ausgibt. Das Hostsystem 60 kann Befehle an den virtualisierten Adressraum ausgeben, ohne sich bewusst zu sein, dass Schreibbefehle zusätzliche Aktualisierungsschreiboperationen einschließen können, damit der Löschcode intakt bleibt.
  • In einer einzelnen Ausführungsform weist das Speichersystem 100 des Weiteren eine Controller-/Virtualisierungseinheit 140 auf, die so konfiguriert ist, dass sie für eine LBA des virtualisierten Adressraums, den das Hostsystem 60 sieht, einen oder mehrere Teile der einen oder der mehreren Speichereinheiten 120, die Datenblöcke und Paritätsblöcke enthalten, welche der LBA entsprechen, erkennt. Die Controller-/Virtualisierungseinheit 140 ordnet physischen Adressen der einen oder der mehreren Speichereinheiten 120 logische Adressen des virtualisierten Adressraums zu (z.B. Zuordnung einer LBA des virtualisierten Adressraums zu PBAs der einen oder der mehreren Speichereinheiten 120, die entsprechende Datenblöcke und Paritätsblöcke enthalten). In einer weiteren Ausführungsform ist die Controller-/Virtualisierungseinheit 140 stattdessen auf dem Hostsystem 60 ausgeführt (wie in 2B gezeigt ist). In noch einer weiteren Ausführungsform ist die Controller-/Virtualisierungseinheit 140 auf einem anderen externen System wie beispielsweise einem Controllersystem 80 ausgeführt (wie in 2C gezeigt ist).
  • Verglichen mit herkömmlichen softwaredefinierten Speichersystemen unterstützt das Framework 50 Änderungen an einem Verhalten des Speichersystems 100 und Änderungen an einer E/A-Schnittstelle zum Hostsystem 60, um eine Verringerung der Anzahl zusätzlicher erforderlicher Schreiboperationen zu erreichen. Genauer gesagt, das Framework 50 erweitert Zuordnungsmetadaten, die in einer internen Umsetzungsschicht 121 von mindestens einer Speichereinheit 120 verwaltet werden. Die erweiterten Zuordnungsmetadaten weisen, ohne darauf beschränkt zu sein, ältere Versionszuordnungsinformationen 125 auf, die eine oder mehrere ältere Versionskopien von einer oder mehreren LBAs (d.h. LBAs für Datenblöcke oder Paritätsblöcke) erkennen und überwachen. Das Framework 50 stellt des Weiteren eine oder mehrere neue E/A-Schnittstellen bereit, die von der Controller-/Virtualisierungseinheit 140 und der einen oder den mehreren Speichereinheiten 120 ausgeführt werden, um die Verarbeitung und die Verwaltung von älteren Versionszuordnungsinformationen zu vereinfachen.
  • Eine interne Umsetzungsschicht 121 einer Speichereinheit 120 ist so konfiguriert, dass sie die folgenden Funktionen ausführt: (1) eine Funktion, um eine PBA der Speichereinheit 120 festzustellen, die zu einer LBA gehört, und (2) eine Funktion, um eine freie PBA der Speichereinheit 120 für eine Schreiboperation abzurufen.
  • Das Framework 50 unterstützt sowohl ein hostorientiertes Modell, bei dem eine Mehrheit von Funktionen im Speicher durchgeführt wird, als auch einen von einem Host verwalteten Ansatz, bei dem notwendige Informationen zur Bereitstellung einer neuen Funktion auf einer Hostebene verfügbar und umsetzbar sind.
  • In einer einzelnen Ausführungsform kann eine LBA, im Gegensatz zu herkömmlichen softwaredefinierten Speichersystemen, einer Mehrzahl von PBAs entsprechen. Zum Beispiel kann eine LBA einer ersten PBA, die einen Datenblock verwaltet, und einer zweiten PBA, die eine ältere Versionskopie des Datenblocks verwaltet, entsprechen. Während eine Ausführungsform von älteren Versionszuordnungsinformationen, die hierin später ausführlich beschrieben wird, eine einzelne ältere Versionskopie von einer oder mehreren LBAs erkennt und überwacht, können ältere Versionszuordnungsinformationen eine Mehrzahl von älteren Versionskopien von einer oder mehreren LBAs erkennen und überwachen.
  • Ältere Versionszuordnungsinformationen können auf mindestens einer Speichereinheit 120 auf mehrere Arten gespeichert werden, wie beispielsweise, ohne darauf beschränkt zu sein, in Hash-Tabellen, Schlüssel-Wert-Speichern, Datenbanken usw. Da erwartet wird, dass eine Gesamtzahl von älteren Versionskopien deutlich kleiner als eine Gesamtzahl von verfügbaren LBAs ist, können ältere Versionskopien in einer einzelnen Ausführungsform zur effizienten Speicherung getrennt gespeichert werden, zum Beispiel unter Verwendung einer dünnbesetzten Datenstruktur, wodurch die Notwendigkeit entfällt, dass in älteren Versionszuordnungsinformationen ein Eintrag für eine ältere Versionskopie einer jeden LBA vorhanden sein muss.
  • In einer einzelnen Ausführungsform wird die Verwaltung von älteren Versionszuordnungsinformationen auf einer Speichereinheit 120 ausgeführt, indem für eine LBA ein erster Zeiger auf eine erste PBA, die eine aktuelle Versionskopie von Daten (d.h. einen aktuellen Datenblock oder einen aktuellen Paritätsblock) für die LBA verwaltet, und ein zweiter Zeiger auf eine zweite PBA, die eine ältere Versionskopie von Daten für die LBA (d.h. einen älteren Datenblock oder einen älteren Paritätsblock) verwaltet, aufgenommen wird. Wie hierin später ausführlich beschrieben wird, vereinfacht das Verwalten von älteren Versionszuordnungsinformationen auf mindestens einer Speichereinheit 120 das Überwachen des Zustands von internen Operationen der mindestens einen Speichereinheit 120 zur Datenwiederherstellung nach einem Stromausfallereignis.
  • Die nachstehende Tabelle 1 stellt einen beispielhaften Eintrag für eine LBA bereit, wobei der Eintrag in einer oder mehreren Ausführungsformen in älteren Versionszuordnungsinformationen auf einer Speichereinheit 120 enthalten ist.
    Feld Beschreibung
    ID Kennung des Eintrags
    LBA Vom Hostsystem 60 gesehene LBA
    Aktuelle PBA PBA der Speichereinheit 120, die eine aktuelle Versionskopie von Daten für die LBA enthält
    Ältere PBA PBA der Speichereinheit 120, die eine ältere Versionskopie von Daten für die LBA enthält
    gwc Global-Write-Complete-Flag
    tsn Transaktionsfolgenummer
    hmd Hostdefinierte Metadaten
  • Wie in der vorstehend bereitgestellten Tabelle 1 gezeigt ist, weist der Eintrag eine Mehrzahl von Feldern auf. Zur Mehrzahl der Felder gehören, ohne darauf beschränkt zu sein, eines oder mehrere der folgenden: (1) ein optionales ID-Feld, das eine lokale Kennung für den Eintrag (z.B. eine Adresse in dem Speicherarray) zur Verwendung bei der internen Verwaltung des Eintrags enthält, (2) ein LBA-Feld, das eine LBA des von dem Hostsystem 60 gesehenen/betrachteten virtualisierten Adressraums enthält, (3) ein Aktuelle-PBA-Feld, das eine PBA der Speichereinheit 120 enthält, die eine aktuelle Versionskopie von Daten für die LBA enthält, (4) ein Ältere-PBA-Feld, das eine andere PBA der Speichereinheit 120 enthält, die eine ältere Versionskopie von Daten für die LBA enthält, (5) ein Global-Write-Complete-(gwc-)Feld, das ein gwc-Flag enthält, welches anzeigt, ob eine Schreiboperation abgeschlossen ist, (6) ein Transaktionsfolgenummer-(tsn-)Feld, das eine Transaktionsfolgenummer (tsn, transaction sequence number) enthält, die über alle Einträge hinweg eindeutig ist, welche in den älteren Versionszuordnungsinformationen auf der Speichereinheit 120 enthalten sind, und (7) ein Hostdefinierte-Metadaten-(hmd)-Feld, das hostdefinierte Metadaten (hmd) enthält.
  • Wenn der Eintrag leer ist, kann das LBA-Feld einen NULL-Wert verwalten, anstatt den Eintrag als leer zu markieren. Wenn eine aktuelle Versionskopie von Daten für die LBA nicht zugewiesen wird, kann das Aktuelle-PBA-Feld stattdessen einen NULL-Wert verwalten. Wenn eine ältere Versionskopie von Daten für die LBA nicht zugewiesen wird, kann das Ältere-PBA-Feld stattdessen einen NULL-Wert verwalten.
  • Zu Erklärungszwecken sei mit dem Begriff „Dateneinheit“ allgemein auf einen Teil einer Speichereinheit 120 verwiesen, zu dem eine oder mehrere PBAs gehören, die einen oder mehrere Datenblöcke enthalten. Mit dem Begriff „Paritätseinheit“ sei allgemein auf einen Teil einer Speichereinheit 120 verwiesen, zu dem eine oder mehrere PBAs gehören, die einen oder mehrere Paritätsblöcke enthalten. Mit dem Begriff „betroffene Dateneinheit“ sei allgemein auf eine Dateneinheit verwiesen, die einen Datenblock enthält, der einen Aktualisierungsschreibvorgang erforderlich macht, um einen ausstehenden Befehl erfolgreich abzuschließen. Mit dem Begriff „betroffene Paritätseinheit“ sei allgemein auf eine Paritätseinheit verwiesen, die einen Paritätsblock enthält, der einen Aktualisierungsschreibvorgang erforderlich macht, um einen ausstehenden Befehl erfolgreich abzuschließen.
  • In einer einzelnen Ausführungsform erkennt hmd eine oder mehrere LBAs für einen oder mehrere Datenblöcke, die an einer ausstehenden Aktualisierungsschreiboperation beteiligt sind, und eine oder mehrere betroffene Dateneinheiten, die den einen oder die mehreren Datenblöcke enthalten. In einer weiteren Ausführungsform kann hmd verwendet werden, um andere hostspezifische Informationen in Verbindung mit der Schreiboperation zu speichern.
  • In einer einzelnen Ausführungsform braucht eine LBA für Daten, die nicht Teil einer ausstehenden Aktualisierungsschreiboperation sind, keinen Eintrag in älteren Versionszuordnungsinformationen auf einer Speichereinheit 120 zu haben.
  • Das Verwalten von älteren Versionszuordnungsinformationen auf mindestens einer Speichereinheit 120 stellt atomare Schreiboperationen in das Speichersystem 100 sicher.
  • In einer einzelnen Ausführungsform führt das Speichersystem 100 einen Einzelparitäts-Löschcode aus. In einer weiteren Ausführungsform führt das Speichersystem 100 Löschcodes mit komplexeren Paritätsgleichungen/-anordnungen aus.
  • 2B veranschaulicht ein weiteres beispielhaftes Framework 51 für Speicher in einer oder mehreren Ausführungsformen. In dem Framework 51 sind die Controller-/Virtualisierungseinheit 140 und der flüchtige Pufferspeicher 110 stattdessen auf dem Hostsystem 60 ausgeführt.
  • Ähnlich dem vorstehend beschriebenen Framework 50 unterstützt das Framework 51 Änderungen an einem Verhalten des Speichersystems 100 und Änderungen an einer E/A-Schnittstelle zum Hostsystem 60, um eine Verringerung der Anzahl zusätzlicher erforderlicher Schreiboperationen zu erreichen. Das Framework 51 stellt eine oder mehrere neue E/A-Schnittstellen bereit, die von der Controller-/Virtualisierungseinheit 140 und der einen oder den mehreren Speichereinheiten 120 über die E/A-Einheiten 61 bzw. 130 ausgeführt werden, um die Verarbeitung und die Verwaltung von älteren Versionszuordnungsinformationen zu vereinfachen. Das Framework 51 unterstützt sowohl ein hostorientiertes Modell, bei dem eine Mehrheit von Funktionen im Speicher durchgeführt wird, als auch einen von einem Host verwalteten Ansatz, bei dem notwendige Informationen zur Bereitstellung einer neuen Funktion auf einer Hostebene verfügbar und umsetzbar sind.
  • 2C veranschaulicht ein weiteres beispielhaftes Framework 52 für Speicher in einer oder mehreren Ausführungsformen. In dem Framework 52 sind die Controller-/Virtualisierungseinheit 140 und der flüchtige Pufferspeicher 110 stattdessen auf einem anderen externen System, wie beispielsweise einem Controllersystem 80, ausgeführt. Das Controllersystem 80 weist des Weiteren eine erste E/A-Einheit 81, die so konfiguriert ist, dass sie Daten mit dem Hostsystem 60 austauscht, und eine zweite E/A-Einheit 82 auf, die so konfiguriert ist, dass sie Daten mit dem Speichersystem 100 austauscht.
  • Ähnlich dem vorstehend beschriebenen Framework 50 unterstützt das Framework 52 Änderungen an einem Verhalten des Speichersystems 100 und Änderungen an einer E/A-Schnittstelle zum Hostsystem 60, um eine Verringerung der Anzahl zusätzlicher erforderlicher Schreiboperationen zu erreichen. Das Framework 52 stellt eine oder mehrere neue E/A-Schnittstellen bereit, die von der Controller-/Virtualisierungseinheit 140 und der einen oder den mehreren Speichereinheiten 120 über die E/A-Einheiten 82 bzw. 130 ausgeführt werden, um die Verarbeitung und die Verwaltung von älteren Versionszuordnungsinformationen zu vereinfachen. Das Framework 52 unterstützt sowohl ein hostorientiertes Modell, bei dem eine Mehrheit von Funktionen im Speicher durchgeführt wird, als auch einen von einem Host verwalteten Ansatz, bei dem notwendige Informationen zur Bereitstellung einer neuen Funktion auf einer Hostebene verfügbar und umsetzbar sind.
  • 3 ist ein Ablaufplan, der einen beispielhaften Prozess 400 zum Ausführen eines hostorientierten Aktualisierungsprotokolls, damit der Einzelparitäts-Löschcode intakt bleibt, in einer oder mehreren Ausführungsformen veranschaulicht. Der Verarbeitungsblock 401 beinhaltet, dass das Hostsystem 60 einen Schreibbefehl an den virtualisierten Adressraum ausgibt. Nehmen wir zum Beispiel an, dass das Hostsystem 60 einen Schreibbefehl (z.B. write(b, d0')) ausgibt, um einen neuen Datenblock d0' an die LBA b des virtualisierten Adressraums zu schreiben. In einer einzelnen Ausführungsform kann der Schreibbefehl auf einen Bereich von zusammenhängenden LBAs verweisen.
  • Der Verarbeitungsblock 402 beinhaltet, dass die Controller-/Virtualisierungseinheit 140 jede betroffene Dateneinheit und jede betroffene Paritätseinheit, die einen Aktualisierungsschreibvorgang erforderlich machen, um den Schreibbefehl erfolgreich abzuschließen, sowie jede LBA, die einer jeden betroffenen Dateneinheit und einer jeden betroffenen Paritätseinheit entspricht, erkennt. Im Verarbeitungsblock 402 erkennt die Controller-/Virtualisierungseinheit 140, dass eine Aktualisierungsschreiboperation erforderlich ist, um den Schreibbefehl erfolgreich abzuschließen.
  • Nehmen wir zum Beispiel an, dass die Controller-/Virtualisierungseinheit 140 erkennt, dass eine betroffene Dateneinheit die Dateneinheit 0 mit der entsprechenden LBA n und eine betroffene Paritätseinheit die Paritätseinheit 3 mit der entsprechenden LBA m ist. Die Controller-/Virtualisierungseinheit 140 gibt einen Lesebefehl (z.B. read(0, n)) auf der Dateneinheit 0 mit der entsprechenden LBA n aus, um einen aktuellen Datenblock d0 (d.h. eine aktuelle Versionskopie) abzurufen, und einen weiteren Lesebefehl (z.B. read(3, m)) auf der Paritätseinheit 3 mit der entsprechenden LBA m, um einen aktuellen Paritätsblock p0 (d.h. eine aktuelle Versionskopie) abzurufen. Die Controller-/Virtualisierungseinheit 140 berechnet dann den neuen Paritätsblock p0', wobei p0' = d0 + d0' + p0.
  • Der Verarbeitungsblock 403 beinhaltet, dass die Controller-/Virtualisierungseinheit 140 eine aktuelle Transaktionsfolgenummer tn erhöht. Die Transaktionsfolgenummer tn entspricht der ausstehenden Aktualisierungsschreiboperation. Der Verarbeitungsblock 403 beinhaltet des Weiteren, dass die Controller-/Virtualisierungseinheit 140 einen Transaktionsdatensatz tr erstellt. Der Transaktionsdatensatz tr weist eine Liste einer jeden betroffenen Dateneinheit, jede LBA, die einer jeden betroffenen Dateneinheit entspricht, und optional einen Zeitstempel auf. Nehmen wir zum Beispiel an, dass die Controller-/Virtualisierungseinheit 140 einen Transaktionsdatensatz tr erstellt, der die Dateneinheit 0, die LBA n und den Zeitstempel time (z.B. createtr(0, n, time)) aufweist.
  • Der Verarbeitungsblock 404 beinhaltet, dass die Controller-/Virtualisierungseinheit 140 eine Aktualisierungsschreiboperation auf jeder betroffenen Dateneinheit und jeder betroffenen Paritätseinheit initiiert, die einen Aktualisierungsschreibvorgang erforderlich macht, um den Schreibbefehl erfolgreich abzuschließen. Nehmen wir zum Beispiel an, dass die Controller-/Virtualisierungseinheit 140 eine Aktualisierungsschreiboperation auf jedem von Folgendem initiiert: der Dateneinheit 0 mit der entsprechenden LBA n, um einen neuen Datenblock d0' zu schreiben (z.B. write(0, n, d0', update, tn, tr)), und der Paritätseinheit 3 mit der entsprechenden LBA m, um einen neuen Paritätsblock p0' zu schreiben (z.B. write(3, m, p0', update, tn, tr)). Die Controller-/Virtualisierungseinheit 140 gibt parallel einen Schreibbefehl an jede betroffene Dateneinheit und jede betroffene Paritätseinheit aus. Jeder ausgegebene Schreibbefehl enthält die folgenden Parameter: ein Aktualisierungsschreibvorgang-Flag update, das gesetzt wird, um anzuzeigen, dass es sich bei dem Schreibbefehl um eine Aktualisierungsschreiboperation, eine Transaktionsfolgenummer tn und einen Transaktionsdatensatz tr handelt.
  • Nachdem die Controller-/Virtualisierungseinheit 140 einen Schreibbefehl an jede betroffene Dateneinheit und jede betroffene Paritätseinheit ausgegeben hat, schaltet die Controller-/Virtualisierungseinheit 140 zum Verarbeitungsblock 405, um auf eine Schreibvorgang-abgeschlossen-Benachrichtigung von jeder betroffenen Dateneinheit und jeder betroffenen Paritätseinheit zu warten. Während die Controller-/Virtualisierungseinheit 140 im Verarbeitungsblock 405 wartet, führt die Dateneinheit 0 Schritte der Verarbeitungsblöcke 421 bis 425 durch und die Paritätseinheit 3 führt Schritte der Verarbeitungsblöcke 441 bis 445 durch. Die Schritte der Verarbeitungsblöcke 421 bis 425 sind asynchron zu den Schritten der Verarbeitungsblöcke 441 bis 445 (d.h., die Abarbeitung der Verarbeitungsblöcke 425 und 445 kann in einer beliebigen Reihenfolge stattfinden).
  • Der Verarbeitungsblock 421 beinhaltet, dass die Dateneinheit 0 als Reaktion auf den Empfang eines Schreibbefehls von der Controller-/Virtualisierungseinheit 140 eine PBA der Dateneinheit 0 feststellt, die der LBA n entspricht (z.B. getPBA(n)). Nehmen wir zum Beispiel an, dass die Dateneinheit 0 über ihre interne Umsetzungsschicht feststellt, dass die PBA j der LBA n entspricht. Der Verarbeitungsblock 421 beinhaltet des Weiteren, dass die Dateneinheit 0 eine Lookup-Suche in ihren älteren Versionszuordnungsinformationen durchführt (die in ihrer internen Umsetzungsschicht verwaltet werden), um einen Eintrag vmed für die LBA n abzurufen (z.B. vmap_find(n)). Der Eintrag vmed erkennt und überwacht eine ältere Versionskopie für die LBA n. Wenn die Lookup-Suche erfolgreich ist, wird der Eintrag vmed zurückgegeben. Der Verarbeitungsblock 421 beinhaltet des Weiteren, dass festgestellt wird, ob ein Zustand der PBA j und der Eintrag vmed für einen Aktualisierungsschreibvorgang gültig sind (z.B. updw_check(j, vmed)). Wenn weder der Zustand der PBA j noch der Eintrag vmed für einen Aktualisierungsschreibvorgang gültig sind, kann ein Fehlerbehebungsprozess aufgerufen werden. Wenn der Zustand der PBA j und der Eintrag vmed für einen Aktualisierungsschreibvorgang gültig sind, schaltet die Dateneinheit 0 zum Verarbeitungsblock 422.
  • Der Verarbeitungsblock 422 beinhaltet, dass die Dateneinheit 0 eine freie PBA k der Dateneinheit 0 zur Verwendung als Ziel-PBA abruft, um einen neuen Datenblock d0' zu schreiben (z.B. getfreePBA()). Ein Fehlerbehebungsprozess kann aufgerufen werden, wenn die Dateneinheit 0 keine freie PBA abrufen kann. Der Verarbeitungsblock 422 beinhaltet des Weiteren, dass die Dateneinheit 0 einen neuen Eintrag für die LBA n zu ihren älteren Versionszuordnungsinformationen hinzufügt (z.B. add_vmap(n, NULL, j, tn, tr)). Zum Beispiel weist der neue Eintrag die folgenden Felder mit den folgenden zugewiesenen Werten auf: (1) das Aktuelle-PBA-Feld, dem der Wert NULL zugewiesen ist, (2) das Ältere-PBA-Feld, dem j zugewiesen ist, (3) das tsn-Feld, dem tn zugewiesen ist, (4) das hmd-Feld, dem tr zugewiesen ist, und (5) das gwc-Feld, das inaktiviert (d.h. nicht gesetzt) ist. Durch das Hinzufügen des neuen Eintrags wird sowohl der aktuelle Datenblock d0, der in der PBA j gespeichert und der LBA n zugeordnet ist, vor dem Löschen oder dem Wiederverwenden bewahrt, wodurch er für Datenwiederherstellungsoperationen (z.B. im Falle eines Stromausfalls) zur Verfügung steht. Da keine Datenblöcke geschrieben werden, ist das Hinzufügen des neuen Eintrags nur mit einer kleinen atomaren Tabellenaktualisierung verbunden.
  • Der Verarbeitungsblock 423 beinhaltet, dass die Dateneinheit 0 einen neuen Datenblock d0' schreibt, um die PBA k freizugeben (z.B. write(k, d0')).
  • Der Verarbeitungsblock 424 beinhaltet, dass die Dateneinheit 0 einen Eintrag in ihren älteren Versionszuordnungsinformationen aktualisiert, der der LBA n entspricht und die Transaktionsfolgenummer tn enthält, indem k dem Aktuelle-PBA-Feld des Eintrags zugewiesen wird (z.B. set_vmap_curr(n, tn, k)). Diese Aktualisierung ist eine atomare Tabellenaktualisierung, die erst stattfindet, nachdem ein neuer Datenblock d0' an die PBA k geschrieben wurde.
  • Der Verarbeitungsblock 425 beinhaltet, dass die Dateneinheit 0 an die Controller-/Virtualisierungseinheit 140 eine Schreibvorgang-abgeschlossen-Benachrichtigung ausgibt, die bestätigt, dass der Schreibbefehl, den sie von der Controller-/Virtualisierungseinheit 140 empfangen hat, abgeschlossen ist.
  • Der Verarbeitungsblock 441 beinhaltet, dass die Paritätseinheit 3 als Reaktion auf den Empfang eines Schreibbefehls von der Controller-/Virtualisierungseinheit 140 eine PBA der Paritätseinheit 3 feststellt, die der LBA m entspricht (z.B. getPBA(m)). Nehmen wir zum Beispiel an, dass die Paritätseinheit 3 über ihre interne Umsetzungsschicht feststellt, dass die PBAF der LBA m entspricht. Der Verarbeitungsblock 441 beinhaltet des Weiteren, dass die Paritätseinheit 3 eine Lookup-Suche in ihren älteren Versionszuordnungsinformationen (die in ihrer internen Umsetzungsschicht verwaltet werden) durchführt, um einen Eintrag vmep für die LBA m abzurufen (z.B. vmap_find(m)). Der Eintrag vmep erkennt und überwacht eine ältere Versionskopie für die LBA m. Wenn die Lookup-Suche erfolgreich ist, wird der Eintrag vmep zurückgegeben. Der Verarbeitungsblock 441 beinhaltet des Weiteren, dass festgestellt wird, ob ein Zustand der PBAF und der Eintrag vmep für einen Aktualisierungsschreibvorgang gültig sind (z.B. updw_check(f, vmep)). Wenn weder der Zustand der PBA f noch der Eintrag vmep für einen Aktualisierungsschreibvorgang gültig sind, kann ein Fehlerbehebungsprozess aufgerufen werden. Wenn der Zustand der PBA f und der Eintrag vmep für einen Aktualisierungsschreibvorgang gültig sind, schaltet die Paritätseinheit 3 zum Verarbeitungsblock 442.
  • Der Verarbeitungsblock 442 beinhaltet, dass die Paritätseinheit 3 eine freie PBA g der Paritätseinheit 3 zur Verwendung als Ziel-PBA abruft, um einen neuen Paritätsblock d0' zu schreiben (z.B. getfreePBA()). Ein Fehlerbehebungsprozess kann aufgerufen werden, wenn die Paritätseinheit 3 keine freie PBA abrufen kann. Der Verarbeitungsblock 442 beinhaltet des Weiteren, dass die Paritätseinheit 3 einen neuen Eintrag für die LBA m zu ihren älteren Versionszuordnungsinformationen hinzufügt (z.B. add_vmap(m, NULL, f, tn, tr)). Zum Beispiel weist der neue Eintrag die folgenden Felder mit den folgenden zugewiesenen Werten auf: (1) das Aktuelle-PBA-Feld, dem der Wert NULL zugewiesen ist, (2) das Ältere-PBA-Feld, dem f zugewiesen ist, (3) das tsn-Feld, dem tn zugewiesen ist, (4) das hmd-Feld, dem tr zugewiesen ist, und (5) das gwc-Feld, das inaktiviert (d.h. nicht gesetzt) ist. Durch das Hinzufügen des neuen Eintrags wird sowohl der aktuelle Paritätsblock p0, der in der PBA f gespeichert und der LBA m zugeordnet ist, vor dem Löschen oder Wiederverwenden bewahrt, wodurch er für Datenwiederherstellungsoperationen (z.B. im Falle eines Stromausfalls) zur Verfügung steht. Da keine Datenblöcke geschrieben werden, ist das Hinzufügen des neuen Eintrags nur mit einer kleinen atomaren Tabellenaktualisierung verbunden.
  • Der Verarbeitungsblock 443 beinhaltet, dass die Paritätseinheit 3 einen neuen Paritätsblock p0' schreibt, um die PBA g freizugeben (z.B. write(g, p0')).
  • Der Verarbeitungsblock 444 beinhaltet, dass die Paritätseinheit 3 einen Eintrag in ihren älteren Versionszuordnungsinformationen aktualisiert, der der LBA m entspricht und die Transaktionsfolgenummer tn enthält, indem g dem Aktuelle-PBA-Feld des Eintrags zugewiesen wird (z.B. set_vmap_curr(n, tn, k)). Diese Aktualisierung ist eine atomare Tabellenaktualisierung, die erst stattfindet, nachdem der neue Paritätsblock p0' an die PBA g geschrieben wurde.
  • Der Verarbeitungsblock 445 beinhaltet, dass die Paritätseinheit 3 an die Controller-/Virtualisierungseinheit 140 eine Schreibvorgang-abgeschlossen-Benachrichtigung ausgibt, die bestätigt, dass der Schreibbefehl, den sie von der Controller-/Virtualisierungseinheit 140 empfangen hat, abgeschlossen ist.
  • Der Verarbeitungsblock 405 beinhaltet, dass die Controller-/Virtualisierungseinheit 140 eine Sperrensynchronisations-(„barrier-sync“-)Operation durchführt, indem sie auf Schreibvorgang-abgeschlossen-Benachrichtigungen von der Dateneinheit 0 und der Paritätseinheit 3 wartet, die bestätigen, dass die ausstehenden Schreibbefehle abgeschlossen sind, welche an die Dateneinheit 0 und die Paritätseinheit 3 ausgegeben wurden. In einer einzelnen Ausführungsform wird ein zusätzlicher Schreibbefehl an eine betroffene Einheit (d.h. eine betroffene Dateneinheit oder eine betroffene Paritätseinheit) gesperrt, bis die Controller-/Virtualisierungseinheit 140 eine Schreibvorgang-abgeschlossen-Benachrichtigung von der betroffenen Einheit empfängt. In einer einzelnen Ausführungsform werden, wenn ältere Versionszuordnungsinformationen, die auf einer betroffenen Einheit verwaltet werden, eine Mehrzahl von älteren Versionskopien für eine LBA erkennen und überwachen, zusätzliche Schreibbefehle an die betroffenen Blöcke (d.h. Datenblöcke und Paritätsblöcke) eines betroffenen Paritätsstripes gesperrt, sobald eine Begrenzung der Gesamtzahl der älteren Versionskopien erreicht ist.
  • Der Verarbeitungsblock 406 beinhaltet, dass die Controller-/Virtualisierungseinheit 140 als Reaktion auf den Empfang einer Schreibvorgang-abgeschlossen-Benachrichtigung von jeder betroffenen Einheit einen globalen Schreibvorgang-abgeschlossen-Befehl an jede betroffene Einheit ausgibt. Nehmen wir zum Beispiel an, dass die Controller-/Virtualisierungseinheit 140 einen globalen Schreibvorgang-abgeschlossen-Befehl an jede der folgenden betroffenen Einheiten ausgibt: die Dateneinheit 0 mit der entsprechenden LBA n (z.B. global_wcomp(0, n, tn)) und die Paritätseinheit 3 mit der entsprechenden LBA m (z.B. global_wcomp(3, m, tn)). Jeder ausgegebene globale Schreibbefehl enthält eine Transaktionsfolgenummer tn als einen Parameter.
  • Nachdem die Controller-/Virtualisierungseinheit 140 einen globalen Schreibbefehl an jede betroffene Einheit ausgegeben hat, schaltet die Controller-/Virtualisierungseinheit 140 zum Verarbeitungsblock 407, um auf eine globale Schreibvorgang-abgeschlossen-Benachrichtigung von jeder betroffenen Einheit zu warten. Während die Controller-/Virtualisierungseinheit 140 im Verarbeitungsblock 407 wartet, führt die Dateneinheit 0 Schritte der Verarbeitungsblöcke 426 bis 427 durch und die Paritätseinheit 3 führt Schritte der Verarbeitungsblöcke 446 bis 447 durch. Die Schritte der Verarbeitungsblöcke 426 bis 427 sind asynchron zu den Schritten der Verarbeitungsblöcke 446 bis 447 (d.h., die Abarbeitung der Verarbeitungsblöcke 427 und 447 kann in einer beliebigen Reihenfolge stattfinden).
  • Der Verarbeitungsblock 426 beinhaltet, dass die Dateneinheit 0 als Reaktion auf den Empfang eines globalen Schreibbefehls von der Controller-/Virtualisierungseinheit 140 einen Eintrag in ihren älteren Versionszuordnungsinformationen aktualisiert, der der LBA n entspricht und die Transaktionsfolgenummer tn enthält, indem sie das gwc-Flag des Eintrags setzt (z.B. set_vmap_gwc(n, tn)). Nachdem sie das gwc-Flag gesetzt hat, schaltet die Dateneinheit 0 zum Verarbeitungsblock 427.
  • Der Verarbeitungsblock 427 beinhaltet, dass die Dateneinheit 0 an die Controller-/Virtualisierungseinheit 140 eine globale Schreibvorgang-abgeschlossen-Benachrichtigung ausgibt, die bestätigt, dass der globale Schreibvorgang-abgeschlossen-Befehl, den sie von der Controller-/Virtualisierungseinheit 140 empfangen hat, abgeschlossen ist.
  • Der Verarbeitungsblock 446 beinhaltet, dass die Paritätseinheit 3 als Reaktion auf den Empfang eines globalen Schreibbefehls von der Controller-/Virtualisierungseinheit 140 einen Eintrag in ihren älteren Versionszuordnungsinformationen aktualisiert, der der LBA m entspricht und die Transaktionsfolgenummer tn enthält, indem sie das gwc-Flag des Eintrags setzt (z.B. set_vmap_gwc(m, tn)). Nachdem sie das gwc-Flag gesetzt hat, schaltet die Paritätseinheit 3 zum Verarbeitungsblock 447.
  • Der Verarbeitungsblock 447 beinhaltet, dass die Paritätseinheit 3 an die Controller-/Virtualisierungseinheit 140 eine globale Schreibvorgang-abgeschlossen-Benachrichtigung ausgibt, die bestätigt, dass der globale Schreibvorgang-abgeschlossen-Befehl, den sie von der Controller-/Virtualisierungseinheit 140 empfangen hat, abgeschlossen ist.
  • Der Verarbeitungsblock 407 beinhaltet, dass die Controller-/Virtualisierungseinheit 140 auf globale Schreibvorgang-abgeschlossen-Benachrichtigungen von der Dateneinheit 0 und der Paritätseinheit 3 wartet, die bestätigen, dass die ausstehenden globalen Schreibbefehle abgeschlossen sind, welche an die Dateneinheit 0 und die Paritätseinheit 3 ausgegeben wurden. In einer einzelnen Ausführungsform führt die Controller-/Virtualisierungseinheit 140 während des Verarbeitungsblocks 407 eine Sperrensynchronisationsoperation aus.
  • Der Verarbeitungsblock 408 beinhaltet, dass die Controller-/Virtualisierungseinheit 140 als Reaktion auf den Empfang einer globalen Schreibvorgang-abgeschlossen-Benachrichtigung von jeder betroffenen Einheit eine Host-Schreibvorgang-abgeschlossen-Benachrichtigung für die LBA b des virtualisierten Adressraums an das Hostsystem 60 ausgibt (z.B. host_writecomp(b)). Der Verarbeitungsblock 408 beinhaltet des Weiteren, dass die Controller-/Virtualisierungseinheit 140 einen Freigabebefehl an jede betroffene Einheit ausgibt, um einen Eintrag in ihren älteren Versionszuordnungsinformationen freizugeben, der einer LBA entspricht, welche der betroffenen Einheit entspricht und eine Transaktionsfolgenummer tn enthält, so dass die Aktualisierungsschreiboperation permanent gespeichert wird. Nehmen wir zum Beispiel an, dass die Controller-/Virtualisierungseinheit 140 einen Freigabebefehl an jede der folgenden betroffenen Einheiten ausgibt: die Dateneinheit 0 mit der entsprechenden LBA n (z.B. free_vmap(0, n, tn)) und die Paritätseinheit 3 mit der entsprechenden LBA m (z.B. free_vmap(3, m, tn)). Jeder ausgegebene Freigabebefehl enthält eine Transaktionsfolgenummer tn als einen Parameter.
  • Nachdem die Controller-/Virtualisierungseinheit 140 einen Freigabebefehl an jede betroffene Einheit ausgegeben hat, schaltet die Controller-/Virtualisierungseinheit 140 zum Verarbeitungsblock 409, um auf eine Freigabe-abgeschlossen-Benachrichtigung von jeder betroffenen Einheit zu warten. Während die Controller-/Virtualisierungseinheit 140 im Verarbeitungsblock 409 wartet, führt die Dateneinheit 0 Schritte der Verarbeitungsblöcke 428 bis 429 durch und die Paritätseinheit 3 führt Schritte der Verarbeitungsblöcke 448 bis 449 durch. Die Schritte der Verarbeitungsblöcke 428 bis 429 sind asynchron zu den Schritten der Verarbeitungsblöcke 448 bis 449 (d.h., die Abarbeitung der Verarbeitungsblöcke 429 und 449 kann in einer beliebigen Reihenfolge stattfinden).
  • Der Verarbeitungsblock 428 beinhaltet, dass die Dateneinheit 0 als Reaktion auf den Empfang eines Freigabebefehls von der Controller-/Virtualisierungseinheit 140 einen Eintrag in ihren älteren Versionszuordnungsinformationen entfernt, der der LBA n entspricht und die Transaktionsfolgenummer tn enthält (z.B. rem_vmap(n, tn)).
  • Der Verarbeitungsblock 449 beinhaltet, dass die Dateneinheit 0 an die Controller-/Virtualisierungseinheit 140 eine Freigabe-abgeschlossen-Benachrichtigung ausgibt, die bestätigt, dass der Freigabebefehl, den sie von der Controller-/Virtualisierungseinheit 140 empfangen hat, abgeschlossen ist.
  • Der Verarbeitungsblock 448 beinhaltet, dass die Paritätseinheit 3 als Reaktion auf den Empfang eines Freigabebefehls von der Controller-/Virtualisierungseinheit 140 einen Eintrag in ihren älteren Versionszuordnungsinformationen entfernt, der der LBA m entspricht und die Transaktionsfolgenummer tn enthält (z.B. rem_vmap(m, tn)).
  • Der Verarbeitungsblock 449 beinhaltet, dass die Paritätseinheit 3 an die Controller-/Virtualisierungseinheit 140 eine Freigabe-abgeschlossen-Benachrichtigung ausgibt, die bestätigt, dass der Freigabebefehl, den sie von der Controller-/Virtualisierungseinheit 140 empfangen hat, abgeschlossen ist.
  • Der Verarbeitungsblock 409 beinhaltet, dass die Controller-/Virtualisierungseinheit 140 auf Freigabe-abgeschlossen-Benachrichtigungen von der Dateneinheit 0 und der Paritätseinheit 3 wartet, die bestätigen, dass die ausstehenden Freigabebefehle abgeschlossen sind, welche an die Dateneinheit 0 und die Paritätseinheit 3 ausgegeben wurden. In einer einzelnen Ausführungsform führt die Controller-/Virtualisierungseinheit 140 während des Verarbeitungsblocks 409 eine Sperrensynchronisationsoperation aus.
  • Der Verarbeitungsblock 410 stellt das Ende des Prozesses 400 dar.
  • Ein hostorientiertes Aktualisierungsschreibvorgang-Protokoll wird in einer dem vorstehend beschriebenen Prozess 400 ähnlichen Weise ausgeführt, wenn das Speichersystem 100 Löschcodes mit komplexeren Paritätsgleichungen/-anordnungen ausführt.
  • Die nachstehende Tabelle 2 stellt während einigen Verarbeitungsblöcken des Prozesses 400 einen Eintrag in älteren Versionszuordnungsinformationen auf der Dateneinheit 0 bereit, der der LBA n entspricht. TABELLE 2
    Feld
    Verarbeitungsblock LBA Aktuelle PBA Ältere PBA gwc tsn hmd
    421 - - - - - -
    422 n NULL j 0 tn 0, n
    424 n k j 0 tn 0, n
    405 Sperrensynchronisation
    426 n k j 1 tn 0, n
    428 - - - - - -
  • Die nachstehende Tabelle 3 stellt während einigen Verarbeitungsblöcken des Prozesses 400 einen Eintrag in älteren Versionszuordnungsinformationen auf der Paritätseinheit 3 bereit, der der LBA m entspricht. TABELLE 3
    Feld
    Verarbeitungsblock LBA Aktuelle PBA Ältere PBA gwc tsn hmd
    441 - - - - - -
    442 m NULL g 0 tn 0, n
    444 m f g 0 tn 0, n
    405 Sperrensynchronisation
    446 m f g 1 tn 0, n
    448 - - - - - -
  • Wie in den vorstehend bereitgestellten Tabellen 2 bis 3 gezeigt ist, wird die Reihenfolge der durch die Dateneinheit 0 durchgeführten Schritte mit der Reihenfolge der durch die Paritätseinheit 3 durchgeführten Schritte nur über eine Sperrensynchronisationsoperation im Verarbeitungsblock 405 synchronisiert. Mit Ausnahme dieses bestimmten Zeitpunkts ist ein Zustand der Dateneinheit 0 in Bezug auf einen Zustand der Paritätseinheit 3 zu anderen Zeitpunkten beliebiger Natur.
  • Wie in Tabelle 2 gezeigt ist, enthalten ältere Versionszuordnungsinformationen auf der Dateneinheit 0 während der Verarbeitungsblöcke 421 und 428 keinen Eintrag für die LBA n. Wie in Tabelle 3 gezeigt ist, enthalten ältere Versionszuordnungsinformationen auf der Paritätseinheit 3 während der Verarbeitungsblöcke 441 und 448 keinen Eintrag für die LBA m.
  • Die nachstehende Tabelle 4 stellt eine Liste von verschiedenen möglichen Zuständen einer betroffenen Einheit in einer oder mehreren Ausführungsformen bereit. Tabelle 4
    Zustand Beschreibung
    501 Es gibt keine anstehende/ausstehende Schreiboperation.
    502 Rückgängigmachen ist möglich
    503 Abschluss der ursprünglichen Schreiboperation ist möglich (Wiederherstellung)
    504 Bereinigung erforderlich
    505 Bereinigung ist auf einer oder mehreren anderen betroffenen Einheiten gegebenenfalls erforderlich
    - Zustand ist ungültig
  • Die nachstehende Tabelle 5 stellt Zustandsinformationen bereit, die Zustände der Dateneinheit 0 und der Paritätseinheit 3 während einiger Verarbeitungsblöcke des Prozesses 400 in einer oder mehreren Ausführungsformen angeben.
    Figure DE112019000849T5_0006
  • Wie in der vorstehend bereitgestellten Tabelle 5 gezeigt ist, ist ein Gesamtzustand des Speichersystems 100 (d.h. der Zustand der Dateneinheit 0 und der Paritätseinheit 3) der Zustand 503 (d.h., ein Abschluss der ursprünglichen Schreiboperation ist möglich (Wiederherstellung)), wenn die Dateneinheit 0 und die Paritätseinheit 3 Schritte der Verarbeitungsblöcke 424 bzw. 441 durchführen.
  • Bei der Wiederherstellung nach einem Stromausfallereignis muss das Speichersystem 100 einen Zustand einer jeden LBA feststellen. In einer einzelnen Ausführungsform kann, um das Speichersystem 100 nach einem Stromausfallereignis wiederherzustellen, ein Zustand einer jeden LBA, die einer jeden betroffenen Einheit entspricht, auf der Grundlage von Zustandsinformationen und älteren Versionszuordnungsinformationen festgestellt werden, wie beispielsweise den in den Tabellen 2 bis 3 enthaltenen älteren Versionszuordnungsinformationen und den in der Tabelle 5 enthaltenen Zustandsinformationen. Wenn zum Beispiel die älteren Versionszuordnungsinformationen auf der Dateneinheit 0 keinen Eintrag für die LBA n enthalten und die älteren Versionszuordnungsinformationen auf der Paritätseinheit 3 keinen Eintrag für die LBA m enthalten (d.h., die Dateneinheit 0 führt entweder Schritte der Verarbeitungsblöcke 421 oder 428 durch und die Paritätseinheit 3 führt entweder Schritte der Verarbeitungsblöcke 441 oder 448 durch), ist ein Gesamtzustand der Speichereinheit 100 (d.h. der Zustand der Dateneinheit 0 und der Zustand der Paritätseinheit 3) der Zustand 501 (d.h., es gibt keine anstehende/ausstehende Schreiboperation).
  • Wenn ein Gesamtzustand des Speichersystems 100 (d.h. der Zustand der Dateneinheit 0 und der Zustand der Paritätseinheit 3) der Zustand 502 ist (d.h., ein Rückgängigmachen ist möglich), enthalten die älteren Versionszuordnungsinformationen auf der Dateneinheit 0 und die älteren Versionszuordnungsinformationen auf der Paritätseinheit 3 eine ältere Versionskopie, aber keine aktuelle Versionskopie. In diesem Zustand kann eine Schreiboperation rückgängig gemacht und ein Zustand wiederhergestellt werden, in dem es ein konsistentes Paritätsstripe gibt, indem eine ältere Versionskopie für eine LBA als eine aktuelle Versionskopie für die LBA wiederhergestellt wird. In einer einzelnen Ausführungsform kann die ältere Versionskopie für die LBA wiederhergestellt werden, indem ein Eintrag entfernt wird, der der LBA aus den älteren Versionszuordnungsinformationen entspricht. Ein Hostsystem 60 kann einen Schreibbefehl wiederholen, wenn das Hostsystem 60 nach der Ausgabe des Schreibbefehls keine Host-Schreibvorgang-abgeschlossen-Benachrichtigung von der Controller-/Virtualisierungseinheit 140 empfängt.
  • Wenn ein Gesamtzustand des Speichersystems 100 (d.h. der Zustand der Dateneinheit 0 und der Zustand der Paritätseinheit 3) der Zustand 503 ist (d.h., ein Abschluss der ursprünglichen Schreiboperation ist möglich), enthalten die älteren Versionszuordnungsinformationen auf der Dateneinheit 0 und die älteren Versionszuordnungsinformationen auf der Paritätseinheit 3 sowohl eine ältere Versionskopie für eine LBA als auch eine aktuelle Versionskopie für die LBA. In diesem Zustand kann ein Schreibbefehl abgeschlossen werden, indem ein neuer Paritätsblock neu berechnet wird.
  • Wenn ein Gesamtzustand des Speichersystems 100 (d.h. der Zustand der Dateneinheit 0 und der Zustand der Paritätseinheit 3) der Zustand 504 ist (d.h., eine Bereinigung ist erforderlich), enthält das Speichersystem 100 ein konsistentes Paritätsstripe, wodurch der von dem Speichersystem 100 ausgeführte Löschcode intakt bleibt. In diesem Zustand ist nur eine Bereinigung erforderlich, um zugehörige Einträge aus älteren Versionszuordnungsinformationen zu entfernen. Jede betroffene Einheit kann eine globale Schreibvorgang-abgeschlossen-Benachrichtigung an das Speichersystem 100 zurückgeben.
  • Wenn ein Gesamtzustand des Speichersystems 100 (d.h. der Zustand der Dateneinheit 0 und der Zustand der Paritätseinheit 3) der Zustand 505 ist (d.h., eine Bereinigung ist auf einer oder mehreren anderen betroffenen Einheiten gegebenenfalls erforderlich), haben einige, aber nicht alle betroffenen Einheiten eine Bereinigung abgeschlossen. Eine Bereinigung ist auf jeder betroffenen Einheit mit einem anstehenden Freigabebefehl erforderlich.
  • In einer einzelnen Ausführungsform stellt jedes Framework 50, 51 und 52 eine oder mehrere neue E/A-Schnittstellen bereit, um die Verarbeitung und Verwaltung von älteren Versionszuordnungsinformationen zu vereinfachen. Zum Beispiel können die eine oder die mehreren neuen E/A-Schnittstellen einen Satz von Befehlen enthalten, um das in 3 veranschaulichte hostorientierte Aktualisierungsschreibvorgang-Protokoll auszuführen und zu verwalten. Die nachstehende Tabelle 6 stellt eine beispielhafte Ausführung des Satzes von Befehlen in einer oder mehreren Ausführungsformen bereit. TABELLE 6
    Befehl Beschreibung
    write(startLBA, LBAcount, data, update, tsn, hmd) Führt eine Schreiboperation auf einem Satz von LBAs durch. startLBA ist eine Start-LBA für die Schreiboperation. LBAcount ist eine Anzahl von zusammenhängenden LBAs. data ist ein flüchtiger Pufferspeicher, der neue Daten hält, die in den Satz von LBAs geschrieben werden sollen. update ist ein Flag, das anzeigt, dass die Schreiboperation eine
    Aktualisierungsschreiboperation ist. tsn ist eine Transaktionsfolgenummer, wenn die Schreiboperation eine Aktualisierungsschreiboperation ist. hmd sind hostdefinierte Metadaten, die gespeichert werden, wenn die Schreiboperation eine Aktualisierungsschreiboperation ist, und den Satz von LBAs und Dateneinheiten angeben, die an der Aktualisierungsschreiboperation beteiligt sind. In einer weiteren Ausführungsform können stattdessen zwei getrennte Schreibbefehle verwendet werden: (1) ein write(startLBA, LBAcount, data) und (2) update_write(startLBA, LBAcount, data, tsn, hmd).
    read(startLBA, LBAcount, data, version, tsn, hmd) Führt eine Leseoperation auf einem Satz von LBAs durch. startLBA ist eine Start-LBA für die Leseoperation. LBAcount ist eine Anzahl von zusammenhängenden LBAs. data ist ein flüchtiger Pufferspeicher, der dazu dient, auf dem Satz von LBAs gelesene Daten zu halten. version gibt eine zu lesende Versionskopie an. Wenn version zum Beispiel 0 ist, wird eine aktuelle Versionskopie (d.h. die neueste Versionskopie) gelesen. tsn ist eine Transaktionsfolgenummer, die zurückgegeben wird, wenn eine ältere Versionskopie gelesen wird. hmd sind hostdefinierte Metadaten, die zurückgegeben und in einem flüchtigen Pufferspeicher gehalten werden, wenn eine ältere Versionskopie gelesen wird.
    global_wcomp(startLBA, LBAcount, tsn) Setzt ein globales Schreibvorgang-abgeschlossen-Flag in älteren Versionszuordnungsinformationen auf einer betroffenen Einheit, die an einer ausstehenden Aktualisierungsschreiboperation beteiligt ist. startLBA ist eine Start-LBA für die Aktualisierungsschreiboperation. LBAcount ist eine Anzahl von zusammenhängenden LBAs. tsn ist eine Transaktionsfolgenummer für die Aktualisierungsschreiboperation.
    free_vmap(startLBA, LBAcount, tsn) Entfernt einen Eintrag, der in älteren Versionszuordnungsinformationen auf einer betroffenen Einheit enthalten ist, die an einer Aktualisierungsschreiboperation beteiligt ist, und markiert eine PBA, die eine ältere Versionskopie enthält, als frei. startLBA ist eine Start-LBA für die Aktualisierungsschreiboperation. LBAcount ist eine Anzahl von zusammenhängenden LBAs. tsn ist eine Transaktionsfolgenummer für die Aktualisierungsschreiboperation.
    clear_vmap() Löscht die gesamten älteren Versionszuordnungsinformationen auf einer Speichereinheit. Dieser Befehl ist für Formatoperationen nützlich.
    read_vmap_entry(startLBA, tsn, buf) Gibt einen Eintrag zurück, der in älteren Versionszuordnungsinformationen auf einer betroffenen Einheit enthalten ist, die an einer Aktualisierungsschreiboperation beteiligt ist. startLBA ist eine Start-LBA für die Aktualisierungsschreiboperation. tsn ist eine Transaktionsfolgenummer für die Aktualisierungsschreiboperation.
    buf ist ein flüchtiger Pufferspeicher, der dazu dient, den zurückgegebenen Eintrag zu halten.
    read_vmap(buf, szbuf) Gibt ältere Versionszuordnungsinformationen auf einer Speichereinheit zurück. Die zurückgegebenen älteren Versionszuordnungsinformationen können bei der Rekonstruktion während einer Datenwiederherstellung nach einem Stromausfallereignis verwendet werden. buf ist ein flüchtiger Pufferspeicher, der dazu dient, die zurückgegebenen älteren Versionszuordnungsinformationen zu halten. szbuf ist eine Größe des buf.
    provision_vmap(naddresses) Legt eine Größe von älteren Versionszuordnungsinformationen auf einer Speichereinheit fest. naddresses ist eine Anzahl von älteren Versionskopien zugewiesenen PBAs.
    inquiry(...) Ein Satz von verschiedenen Abfragebefehlen, um Aspekte einer Ausführung wie beispielsweise Unterstützung, maximale Bereitstellungsgröße, Parameter usw. festzustellen.
  • Zum Beispiel wird der Satz von Befehlen in dem Framework 50 von der Controller-/Virtualisierungseinheit 140 und der einen oder den mehreren Speichereinheiten 120 ausgeführt. Als ein weiteres Beispiel wird der Satz von Befehlen in dem Framework 51 von der Controller-/Virtualisierungseinheit 140 und der einen oder den mehreren Speichereinheiten 120 über die E/A-Einheiten 61 bzw. 130 ausgeführt. Als noch ein weiteres Beispiel wird der Satz von Befehlen in dem Framework 52 von der Controller-/Virtualisierungseinheit 140 und der einen oder den mehreren Speichereinheiten 120 über die E/A-Einheiten 82 bzw. 130 ausgeführt.
  • Jedes Framework 50, 51 und 52 ist auf eine beliebige Situation anwendbar, in der Aktualisierungsschreiboperationen über verteilte Speichereinheiten, darunter Dateisysteme, Datenbanken usw., atomar sein müssen.
  • 4 ist ein Übersichtsblockschaltbild, das ein Informationsverarbeitungssystem 300 zeigt, welches zur Ausführung einer einzelnen Ausführungsform der Erfindung nützlich ist. Das Computersystem enthält einen oder mehrere Prozessoren wie beispielsweise den Prozessor 302. Der Prozessor 302 ist mit einer Übertragungsinfrastruktur 304 (z.B. einem Übertragungsbus, einem Crossover-Bar oder einem Netzwerk) verbunden.
  • Das Computersystem kann eine Bildschirmschnittstelle 306 enthalten, die Grafiken, Text und andere Daten aus der Übertragungsinfrastruktur 304 (oder aus einem Bildspeicher, der nicht gezeigt ist) zur Anzeige auf einer Bildschirmeinheit 308 weiterleitet. Das Computersystem enthält auch einen Hauptspeicher 310, vorzugsweise einen Direktzugriffsspeicher (RAM), und kann auch einen Sekundärspeicher 312 enthalten. Der Sekundärspeicher 312 kann zum Beispiel ein Festplattenlaufwerk 314 und/oder ein austauschbares Speicherlaufwerk 316 enthalten, das zum Beispiel ein Diskettenlaufwerk, ein Magnetbandlaufwerk oder ein optisches Plattenlaufwerk darstellt. Das austauschbare Speicherlaufwerk 316 liest von einer austauschbaren Speichereinheit 318 und/oder schreibt auf eine austauschbare Speichereinheit 318 in einer dem Fachmann bekannten Art und Weise. Die austauschbare Speichereinheit 318 stellt zum Beispiel eine Diskette, eine Compact-Disk, ein Magnetband oder eine optische Platte usw. dar, die bzw. das von der austauschbaren Speichereinheit 316 gelesen und auf die bzw. das von der austauschbaren Speichereinheit 316 geschrieben wird. Wie erkannt wird, enthält die austauschbare Speichereinheit 318 einen durch einen Computer lesbaren Datenträger mit darin gespeicherter Computer-Software und/oder Daten.
  • In alternativen Ausführungsformen kann der Sekundärspeicher 312 andere ähnliche Mittel enthalten, damit Computerprogramme oder andere Anweisungen in das Computersystem geladen werden können. Zu solchen Mitteln können zum Beispiel eine austauschbare Speichereinheit 320 und eine Schnittstelle 322 gehören. Zu Beispielen für solche Mittel können ein Programmpaket und eine Paketschnittstelle (wie sie beispielsweise in Videospielgeräten zu finden ist), ein austauschbarer Speicherchip (wie beispielsweise ein EPROM oder PROM) und ein zugehöriger Stecksockel sowie andere austauschbare Speichereinheiten 320 und Schnittstellen 322 gehören, die eine Übertragung von Software und Daten von der austauschbaren Speichereinheit 320 an das Computersystem ermöglichen.
  • Das Computersystem kann auch eine Übertragungsschnittstelle 324 enthalten. Die Übertragungsschnittstelle 324 ermöglicht eine Übertragung von Software und Daten zwischen dem Computersystem und externen Einheiten. Zu Beispielen für die Übertragungsschnittstelle 324 können ein Modem, eine Netzwerkschnittstelle (wie beispielsweise eine Ethernet-Karte), ein Übertragungsanschluss oder ein PCMCIA-Steckplatz und eine PCMCIA-Karte usw. gehören. Über die Übertragungsschnittstelle 324 übertragene Software und Daten liegen in Form von Signalen vor, bei denen es sich zum Beispiel um elektronische, elektromagnetische, optische oder andere Signale handeln kann, die von der Übertragungsschnittstelle 324 empfangen werden können. Diese Signale werden der Übertragungsschnittstelle 324 über einen Übertragungsweg (d.h. Kanal) 326 bereitgestellt. Dieser Übertragungsweg 326 überträgt Signale und kann mittels Draht oder Kabel, Lichtwellenleitertechnik, einer Telefonleitung, einer Mobilfunkverbindung, einer HF-Verbindung und/oder anderer Übertragungskanäle ausgeführt sein.
  • Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen. Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder gehobene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. durch ein Glasfaserkabel geleitete Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
  • Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
  • Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, im Feld programmierbare Gatter-Anordnungen (FPGA, field-programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
  • Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
  • Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Informationsverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Informationsverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Informationsverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
  • Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Informationsverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
  • Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme, welche die festgelegten Funktionen oder Schritte durchführen oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen, umgesetzt werden können.
  • Aus der vorstehenden Beschreibung geht hervor, dass die vorliegende Erfindung ein System, ein Computerprogrammprodukt und ein Verfahren zur Ausführung der erfindungsgemäßen Ausführungsformen bereitstellt. Die vorliegende Erfindung stellt des Weiteren ein nicht flüchtiges, durch einen Computer verwendbares Speichermedium zur Ausführung der erfindungsgemäßen Ausführungsformen bereit. Das nicht flüchtige, durch einen Computer verwendbare Speichermedium verfügt über ein durch einen Computer lesbares Programm, wobei das Programm bei seiner Verarbeitung auf einem Computer den Computer veranlasst, die Schritte der vorliegenden Erfindung gemäß den hierin beschriebenen Ausführungsformen auszuführen. Verweise in den Ansprüchen auf ein Element im Singular sollen nicht „ein einziges“ bedeuten, sofern dies nicht ausdrücklich so angegeben ist, sondern vielmehr „eines oder mehrere“. Alle strukturellen und funktionalen Äquivalente zu den Elementen der vorstehend beschriebenen beispielhaften Ausführungsform, die dem Fachmann derzeit bekannt sind oder später bekannt werden, sollen von den vorliegenden Ansprüchen abgedeckt sein. Kein Anspruchselement hierin soll gemäß den Bestimmungen des 35 U.S.C. 112, sechster Abschnitt, ausgelegt werden, sofern das Element nicht ausdrücklich unter Verwendung der Formulierung „Mittel für“ oder „Schritt für“ angeführt wird.
  • Die hierin verwendete Terminologie dient lediglich dazu, bestimmte Ausführungsformen zu beschreiben, und sollte nicht als Einschränkung der Erfindung verstanden werden. In der Verwendung hierin sollen die Singular-Formen „ein“, „eine“ und „der“, „die“, „das“ auch die Pluralformen einschließen, sofern der Kontext nicht eindeutig etwas anderes angibt. Es wird des Weiteren darauf hingewiesen, dass die Begriffe „aufweist“ und/oder „aufweisend“, wenn sie in dieser Beschreibung verwendet werden, das Vorhandensein von angegebenen Merkmalen, Ganzen Zahlen, Schritten, Operationen, Elementen und/oder Komponenten bezeichnen, das Vorhandensein oder das Hinzufügen von einem oder mehreren anderen/weiteren Merkmalen, Ganzen Zahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon jedoch nicht ausschließen.
  • Die entsprechenden Strukturen, Materialien, Vorgänge und Äquivalente von allen Mitteln oder Schritt-plus-Funktion-Elementen (step plus function elements) in den nachstehenden Ansprüchen sollen jedwede Struktur, jedwedes Material oder jedweden Vorgang zur Durchführung der Funktion in Kombination mit anderen beanspruchten Elementen, die im Einzelnen beansprucht werden, mit einschließen. Die Beschreibung der vorliegenden Erfindung erfolgte zum Zweck der Veranschaulichung und Erläuterung, soll aber nicht erschöpfend oder auf die Erfindung in der offenbarten Form beschränkt sein. Viele Änderungen und Varianten sind für den Fachmann erkennbar, ohne vom Umfang und Wesen der Erfindung abzuweichen. Die Ausführungsform wurde gewählt und beschrieben, um die Grundgedanken der Erfindung und die praktische Anwendung bestmöglich zu erklären und um anderen Fachleuten das Verständnis der Erfindung hinsichtlich verschiedener Ausführungsformen mit verschiedenen Änderungen, wie sie für die jeweilige vorgesehene Verwendung geeignet sind, zu ermöglichen.

Claims (20)

  1. Verfahren, das aufweist: Verwalten, auf einer Speichereinheit, von Zuordnungsdaten zwischen einem ersten Satz von logischen Adressen, die von einem Host betrachtet werden, und einem ersten Satz von physischen Adressen sowie einem zweiten Satz von physischen Adressen der Speichereinheit, wobei eine erste logische Adresse des ersten Satzes von logischen Adressen einer ersten physischen Adresse des ersten Satzes von physischen Adressen entspricht, die aktuelle Daten für die erste logische Adresse verwaltet, und wobei die erste logische Adresse des Weiteren einer zweiten physischen Adresse des zweiten Satzes von physischen Adressen entspricht, die ältere Daten für die erste logische Adresse verwaltet; und Empfangen, an der Speichereinheit, eines Befehls von dem Host zum Durchführen einer Multi-Device-Operation, an der die erste logische Adresse beteiligt ist, wobei die Operation atomar durchgeführt wird.
  2. Verfahren nach Anspruch 1, wobei die Operation eine Aktualisierungsschreiboperation ist.
  3. Verfahren nach Anspruch 2, wobei die Zuordnungsdaten eine oder mehrere ältere Versionskopien für die erste logische Adresse erkennen und überwachen, und wobei die Zuordnungsdaten für jede ältere Versionskopie für die erste logische Adresse eine entsprechende physische Adresse aufweisen, welche die ältere Versionskopie verwaltet.
  4. Verfahren nach Anspruch 2, wobei die Zuordnungsdaten eine Transaktionsfolgenummer für die Aktualisierungsschreiboperation enthalten.
  5. Verfahren nach Anspruch 2, wobei die Zuordnungsdaten hostdefinierte Metadaten enthalten, die jede an der Aktualisierungsschreiboperation beteiligte Speichereinheit angeben.
  6. Verfahren nach Anspruch 4, wobei die Operation als Reaktion darauf abgeschlossen ist, dass der Host von der Speichereinheit die folgenden Benachrichtigungen empfängt, die Multi-Device-Atomizität angeben: eine Benachrichtigung, die bestätigt, dass ein Aktualisierungsschreibvorgang auf der Speichereinheit abgeschlossen ist, eine Benachrichtigung, die bestätigt, dass ein globales Schreibvorgang-abgeschlossen-Flag gesetzt ist, und eine Benachrichtigung, die bestätigt, dass ein Eintrag in den Zuordnungsdaten, der der ersten logischen Adresse entspricht und die Transaktionsfolgenummer enthält, aus den Zuordnungsdaten entfernt ist.
  7. Verfahren nach Anspruch 1, wobei die aktuellen Daten einen aktuellen Datenblock aufweisen und die älteren Daten einen älteren Datenblock aufweisen.
  8. Verfahren nach Anspruch 1, wobei die aktuellen Daten einen aktuellen Paritätsblock aufweisen und die älteren Daten einen älteren Paritätsblock aufweisen.
  9. System, das aufweist: mindestens einen Prozessor; und eine nicht flüchtige, durch einen Prozessor lesbare Hauptspeichereinheit, die Anweisungen speichert, die, wenn sie von dem mindestens einen Prozessor ausgeführt werden, den mindestens einen Prozessor zur Durchführung von Operationen veranlassen, darunter: Verwalten, auf einer Speichereinheit, von Zuordnungsdaten zwischen einem ersten Satz von logischen Adressen, die von einem Host betrachtet werden, und einem ersten Satz von physischen Adressen sowie einem zweiten Satz von physischen Adressen der Speichereinheit, wobei eine erste logische Adresse des ersten Satzes von logischen Adressen einer ersten physischen Adresse des ersten Satzes von physischen Adressen entspricht, die aktuelle Daten für die erste logische Adresse verwaltet, und wobei die erste logische Adresse des Weiteren einer zweiten physischen Adresse des zweiten Satzes von physischen Adressen entspricht, die ältere Daten für die erste logische Adresse verwaltet; und Empfangen, an der Speichereinheit, eines Befehls von dem Host zum Durchführen einer Multi-Device-Operation, an der die erste logische Adresse beteiligt ist, wobei die Operation atomar durchgeführt wird.
  10. System nach Anspruch 9, wobei die Operation eine Aktualisierungsschreiboperation ist.
  11. System nach Anspruch 10, wobei die Zuordnungsdaten eine oder mehrere ältere Versionskopien für die erste logische Adresse erkennen und überwachen, und wobei die Zuordnungsdaten für jede ältere Versionskopie für die erste logische Adresse eine entsprechende physische Adresse aufweisen, welche die ältere Versionskopie verwaltet.
  12. System nach Anspruch 10, wobei die Zuordnungsdaten eine Transaktionsfolgenummer für die Aktualisierungsschreiboperation enthalten.
  13. System nach Anspruch 10, wobei die Zuordnungsdaten hostdefinierte Metadaten enthalten, die jede an der Aktualisierungsschreiboperation beteiligte Speichereinheit angeben.
  14. System nach Anspruch 12, wobei die Operation als Reaktion darauf abgeschlossen ist, dass der Host von der Speichereinheit die folgenden Benachrichtigungen empfängt, die Multi-Device-Atomizität angeben: eine Benachrichtigung, die bestätigt, dass ein Aktualisierungsschreibvorgang auf der Speichereinheit abgeschlossen ist, eine Benachrichtigung, die bestätigt, dass ein globales Schreibvorgang-abgeschlossen-Flag gesetzt ist, und eine Benachrichtigung, die bestätigt, dass ein Eintrag in den Zuordnungsdaten, der der ersten logischen Adresse entspricht und die Transaktionsfolgenummer enthält, aus den Zuordnungsdaten entfernt ist.
  15. System nach Anspruch 9, wobei die aktuellen Daten einen aktuellen Datenblock aufweisen und die älteren Daten einen älteren Datenblock aufweisen.
  16. System nach Anspruch 9, wobei die aktuellen Daten einen aktuellen Paritätsblock aufweisen und die älteren Daten einen älteren Paritätsblock aufweisen.
  17. Computerprogrammprodukt, das ein durch einen Computer lesbares Hardware-Speichermedium mit damit realisiertem Programmcode aufweist, wobei der Programmcode durch einen Computer ausführbar ist, um ein Verfahren auszuführen, welches umfasst: Verwalten, auf einer Speichereinheit, von Zuordnungsdaten zwischen einem ersten Satz von logischen Adressen, die von einem Host betrachtet werden, und einem ersten Satz von physischen Adressen sowie einem zweiten Satz von physischen Adressen der Speichereinheit, wobei eine erste logische Adresse des ersten Satzes von logischen Adressen einer ersten physischen Adresse des ersten Satzes von physischen Adressen entspricht, die aktuelle Daten für die erste logische Adresse verwaltet, und wobei die erste logische Adresse des Weiteren einer zweiten physischen Adresse des zweiten Satzes von physischen Adressen entspricht, die ältere Daten für die erste logische Adresse verwaltet; und Empfangen, an der Speichereinheit, eines Befehls von dem Host zum Durchführen einer Multi-Device-Operation, an der die erste logische Adresse beteiligt ist, wobei die Operation atomar durchgeführt wird.
  18. Computerprogrammprodukt nach Anspruch 17, wobei die Operation eine Aktualisierungsschreiboperation ist.
  19. Computerprogrammprodukt nach Anspruch 18, wobei die Zuordnungsdaten eine oder mehrere ältere Versionskopien für die erste logische Adresse erkennen und überwachen, und wobei die Zuordnungsdaten für jede ältere Versionskopie für die erste logische Adresse eine entsprechende physische Adresse aufweisen, welche die ältere Versionskopie verwaltet.
  20. Computerprogrammprodukt nach Anspruch 18, wobei die Zuordnungsdaten eine Transaktionsfolgenummer für die Aktualisierungsschreiboperation enthalten.
DE112019000849.8T 2018-05-09 2019-04-25 Hostorientierter Aktualisierungsschreibvorgang Pending DE112019000849T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/975,584 US11099980B2 (en) 2018-05-09 2018-05-09 Host aware update write
US15/975,584 2018-05-09
PCT/IB2019/053419 WO2019215532A1 (en) 2018-05-09 2019-04-25 Host aware update write

Publications (1)

Publication Number Publication Date
DE112019000849T5 true DE112019000849T5 (de) 2020-11-05

Family

ID=68464720

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112019000849.8T Pending DE112019000849T5 (de) 2018-05-09 2019-04-25 Hostorientierter Aktualisierungsschreibvorgang

Country Status (6)

Country Link
US (1) US11099980B2 (de)
JP (1) JP7189965B2 (de)
CN (1) CN112088366A (de)
DE (1) DE112019000849T5 (de)
GB (1) GB2586430B (de)
WO (1) WO2019215532A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200099882A (ko) * 2019-02-15 2020-08-25 에스케이하이닉스 주식회사 메모리 컨트롤러 및 그 동작 방법
CN111371888B (zh) * 2020-03-02 2021-07-09 西南交通大学 一种基于纠删编码的多源数据传输系统及方法
US11360888B1 (en) * 2021-02-16 2022-06-14 Micron Technology, Inc. Host system notification based on entry miss
CN114968088B (zh) * 2022-04-08 2023-09-05 中移互联网有限公司 文件存储方法、文件读取方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1345113A3 (de) 2002-03-13 2008-02-06 Hitachi, Ltd. Verwaltungsserver
US7487308B1 (en) * 2003-11-28 2009-02-03 Symantec Operating Corporation Identification for reservation of replacement storage devices for a logical volume to satisfy its intent
US7426625B2 (en) 2004-03-31 2008-09-16 International Business Machines Corporation Data processing system and computer program product for support of system memory addresses with holes
KR101473344B1 (ko) 2007-08-24 2014-12-17 삼성전자 주식회사 플래시 메모리를 스토리지로 사용하는 장치 및 그 동작방법
CN101826053B (zh) * 2009-03-03 2012-05-30 慧国(上海)软件科技有限公司 闪存的存取方法及闪存装置
CN101976182A (zh) 2010-11-15 2011-02-16 记忆科技(深圳)有限公司 一种固态硬盘预读取的方法及其装置
US9164888B2 (en) * 2012-12-10 2015-10-20 Google Inc. Using a logical to physical map for direct user space communication with a data storage device
GB2527529B (en) 2014-06-24 2021-07-14 Advanced Risc Mach Ltd A device controller and method for performing a plurality of write transactions atomically within a non-volatile data storage device
WO2016051512A1 (ja) 2014-09-30 2016-04-07 株式会社日立製作所 分散型ストレージシステム
US9671971B2 (en) 2015-03-27 2017-06-06 Intel Corporation Managing prior versions of data for logical addresses in a storage device
CN105005535B (zh) * 2015-07-22 2018-04-20 清华大学 一种分布式闪存事务处理方法
US9910786B2 (en) * 2015-11-03 2018-03-06 Intel Corporation Efficient redundant array of independent disks (RAID) write hole solutions

Also Published As

Publication number Publication date
WO2019215532A1 (en) 2019-11-14
JP2021522577A (ja) 2021-08-30
US11099980B2 (en) 2021-08-24
CN112088366A (zh) 2020-12-15
US20190347191A1 (en) 2019-11-14
GB2586430B (en) 2021-08-04
JP7189965B2 (ja) 2022-12-14
GB202019203D0 (en) 2021-01-20
GB2586430A (en) 2021-02-17

Similar Documents

Publication Publication Date Title
DE112019000849T5 (de) Hostorientierter Aktualisierungsschreibvorgang
DE60312746T2 (de) Wiederherstellung nach fehlern in datenverarbeitungsanlagen
DE102013204972B4 (de) Hybride Sicherung und Wiederherstellung eines sehr grossen Dateisystems unter Verwendung von Metadaten-Abbildsicherung und herkömmlicher Sicherung
DE60213867T2 (de) Vorrichtung zur verwaltung von datenreplikation
DE602004006404T2 (de) Flashback-datenbank
DE602005000819T2 (de) Aufrechterhaltung der konsistenz einer fernkopie unter verwendung von virtualisierung
DE112020000749T5 (de) Indexerstellung für sich entwickelnde umfangreiche Datensätze in Hybriden Transaktions- und Analysenverarbeitungssystemen mit mehreren Mastern
DE102008015662B4 (de) Beseitigung von Daten
DE202009019149U1 (de) Asynchron verteilte Speicherbereinigung für replizierte Speichercluster
DE112010003262B4 (de) Synchronisierung replizierter sequenzieller Zugriffsspeicherkomponenten
DE112013004400B4 (de) Herstellen einer Zeitpunktkopie-Beziehung zwischen logischen Quellenadressen und logischen Zieladressen
DE112014002051T5 (de) Sichern und Wiederherstellen einer Anwendung
DE112010004573T5 (de) System und verfahren zur optimierten wiedernutzbarmachungsverarbeitung in einem virtuellen bandbibliotheksystem
DE102013208930A1 (de) Zusammenfassen von Einträgen in einem Deduplizierungs-lndex
DE112014001873T5 (de) Replikation für Hot-Standby-Online-Datenbank
DE112015000343T5 (de) Erstellen einer Wiederherstellungskopie von einer Quelldaten-Kopie in einem Repository, das Quelldaten an verschiedenen Zeitpunkten aufweist
DE202013012496U1 (de) Systeme für asynchrone Schemaänderungen
DE112015000222T5 (de) Zusammenführen von mehreren Zeitpunktkopien zu einer zusammengeführten Zeitpunktkopie
DE112017000190T5 (de) Durchgehende Verschlüsselung und Backup in Datenschutzumgebungen
DE202010018481U1 (de) Asynchroner verteilter Objekt-Upload für replizierte Assoziativspeichercluster
DE112019000143T5 (de) Versionierungsvalidierung für die datenübertragung zwischen heterogenen datenspeichern
DE112010004947T5 (de) Wiederherstellung einer vollständigen Systemsicherung und inkrementeller Sicherungen unter Verwendung von mehreren gleichzeitigen Datenströmen von Einheiten
DE112011100618T5 (de) Verwalten von Schreiboperationen auf einen Speicherbereich von Spuren, der zwischen Speichereinheiten verlagert wird
DE102016204710A1 (de) Sichern und Wiederherstellen von Klondaten
DE112011101793T5 (de) Gemeinsame Datennutzung bei Dateiklonen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R084 Declaration of willingness to licence