DE102021127271A1

DE102021127271A1 - Schreiben eines containerindexes in den permanenten speicher

Info

Publication number: DE102021127271A1
Application number: DE102021127271.8A
Authority: DE
Inventors: David Malcolm Falkinder; Richard Phillip MAYO
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-11-06
Filing date: 2021-10-21
Publication date: 2022-05-12
Also published as: US20220147264A1; CN114442919A; US11593021B2; CN114442919B

Abstract

Beispielimplementierungen beziehen sich auf Metadatenoperationen in einem Speichersystem. Ein Beispielverfahren umfasst den Empfang einer ersten Schreibanforderung für einen ersten Containerindex im Speicher von einem ersten Stromprozess. Das Verfahren umfasst ferner, als Reaktion auf den Empfang der ersten Schreibanforderung, das Senden eines ersten Tokens an den ersten Stromprozess, ohne den ersten Containerindex in einen dauerhaften Speicher zu schreiben. Das Verfahren umfasst ferner den Empfang einer ersten Beendigungsanforderung für den ersten Container-Index von einem zweiten Stromprozess. Das Verfahren umfasst ferner, als Reaktion auf den Empfang der ersten Vervollständigungsanforderung, das Schreiben des ersten Container-Index aus dem Speicher in den dauerhaften Speicher.

Description

Hintergrund
Techniken zur Datenreduzierung können angewandt werden, um die Menge der in einem Speichersystem gespeicherten Daten zu verringern. Ein Beispiel für ein Datenreduktionsverfahren ist die Datendeduplizierung. Die Datendeduplizierung identifiziert doppelte Dateneinheiten und versucht, die Anzahl der im Speichersystem gespeicherten doppelten Dateneinheiten zu reduzieren oder zu eliminieren.
Figurenliste
Einige Ausführungsformen werden anhand der folgenden Abbildungen beschrieben.

ist ein schematisches Diagramm eines beispielhaften Speichersystems gemäß einigen Ausführungsformen.
zeigt ein Beispiel für Datenstrukturen in Übereinstimmung mit einigen Implementierungen.
ist eine Darstellung von Beispiel-Datenstrukturen in Übereinstimmung mit einigen Implementierungen.
ist eine Illustration eines Beispielsystems in Übereinstimmung mit einigen Implementierungen.
ist eine Illustration eines Beispielvorgangs in Übereinstimmung mit einigen Implementierungen.
ist eine Darstellung einer beispielhaften Datenstruktur in Übereinstimmung mit einigen Implementierungen.
ist eine Illustration eines Beispielprozesses in Übereinstimmung mit einigen Implementierungen.
ist eine Illustration eines Beispielprozesses in Übereinstimmung mit einigen Implementierungen.
ist ein Diagramm eines maschinenlesbaren Mediums, das Befehle in Übereinstimmung mit einigen Implementierungen speichert.
ist ein schematisches Diagramm eines Beispiel-Computergeräts in Übereinstimmung mit einigen Implementierungen.

In den Zeichnungen bezeichnen identische Referenznummern ähnliche, aber nicht unbedingt identische Elemente. Die Abbildungen sind nicht unbedingt maßstabsgetreu, und die Größe einiger Teile kann übertrieben sein, um das gezeigte Beispiel deutlicher zu machen. Darüber hinaus enthalten die Zeichnungen Beispiele und/oder Ausführungsformen, die mit der Beschreibung übereinstimmen; die Beschreibung ist jedoch nicht auf die in den Zeichnungen dargestellten Beispiele und/oder Ausführungsformen beschränkt.
Detaillierte Beschreibung
In der vorliegenden Offenlegung schließt die Verwendung des Begriffs „ein“, „ein“ oder „die“ auch die Pluralformen ein, sofern aus dem Kontext nicht eindeutig etwas anderes hervorgeht. Auch der Begriff „umfasst“, „einschließlich“, „umfasst“, „umfasst“, „haben“ oder „haben“, wenn er in dieser Offenlegung verwendet wird, spezifiziert das Vorhandensein der angegebenen Elemente, schließt aber das Vorhandensein oder die Zugabe anderer Elemente nicht aus.
In einigen Beispielen kann ein Speichersystem Daten deduplizieren, um den für die Speicherung der Daten erforderlichen Speicherplatz zu reduzieren. Das Speichersystem kann einen Deduplizierungsprozess durchführen, bei dem ein Datenstrom in diskrete Dateneinheiten oder „Chunks“ unterteilt wird. „Darüber hinaus kann das Speichersystem Identifikatoren oder „Fingerabdrücke“ eingehender Dateneinheiten ermitteln und feststellen, welche eingehenden Dateneinheiten Duplikate von zuvor gespeicherten Dateneinheiten sind. Im Falle von Dateneinheiten, bei denen es sich um Duplikate handelt, kann das Speichersystem Verweise auf die vorherigen Dateneinheiten speichern, anstatt die doppelten eingehenden Dateneinheiten zu speichern.
Wie hier verwendet, bezieht sich der Begriff „Fingerabdruck“ auf einen Wert, der durch Anwendung einer Funktion auf den Inhalt der Dateneinheit abgeleitet wird (wobei der „Inhalt“ die Gesamtheit oder eine Teilmenge des Inhalts der Dateneinheit umfassen kann). Ein Beispiel für eine Funktion, die angewendet werden kann, ist eine Hash-Funktion, die einen Hash-Wert auf der Grundlage der eingehenden Dateneinheit erzeugt. Beispiele für Hash-Funktionen sind kryptografische Hash-Funktionen wie die Hash-Funktionen des Secure Hash Algorithm 2 (SHA-2), z. B. SHA-224, SHA-256, SHA-384, usw. In anderen Beispielen können auch andere Arten von Hash-Funktionen oder andere Arten von Fingerprint-Funktionen verwendet werden.
Ein „Speichersystem“ kann ein Speichergerät oder eine Anordnung von Speichergeräten umfassen. Ein Speichersystem kann auch einen oder mehrere Speicher-Controller enthalten, die den Zugriff auf das/die Speichergerät(e) verwalten. Eine „Dateneinheit“ kann sich auf jeden Teil der Daten beziehen, der im Speichersystem separat identifiziert werden kann. In einigen Fällen kann sich eine Dateneinheit auf einen Chunk, eine Sammlung von Chunks oder einen anderen Teil von Daten beziehen. In einigen Beispielen kann ein Speichersystem Dateneinheiten in einem persistenten Speicher speichern. Die dauerhafte Speicherung kann mit einem oder mehreren dauerhaften (z. B. nichtflüchtigen) Speichergeräten, wie plattenbasierten Speichergeräten (z. B. Festplattenlaufwerken (HDDs)), Solid-State-Geräten (SSDs), wie Flash-Speichergeräten oder Ähnlichem, oder einer Kombination davon realisiert werden.
Ein „Steuergerät“ kann sich auf einen Hardware-Verarbeitungsschaltkreis beziehen, der eine beliebige oder eine Kombination aus einem Mikroprozessor, einem Kern eines Multi-Core-Mikroprozessors, einem Mikrocontroller, einem programmierbaren integrierten Schaltkreis, einem programmierbaren Gate-Array, einem digitalen Signalprozessor oder einem anderen Hardware-Verarbeitungsschaltkreis umfassen kann. Alternativ kann sich ein „Steuergerät“ auf eine Kombination aus einer Hardware-Verarbeitungsschaltung und maschinenlesbaren Anweisungen (Software und/oder Firmware) beziehen, die auf der Hardware-Verarbeitungsschaltung ausführbar sind.
In einigen Beispielen kann ein Deduplizierungsspeichersystem Metadaten für die Verarbeitung eines oder mehrerer eingehender Datenströme (z. B. mehrerer gleichzeitiger eingehender Datenströme) verwenden. Solche Metadaten können zum Beispiel Datenrezepte (hier auch als „Manifeste“ bezeichnet) enthalten, die die Reihenfolge angeben, in der bestimmte Dateneinheiten (z. B. in einem Datenstrom) empfangen werden. Anschließend kann das Deduplizierungssystem als Reaktion auf eine Leseanforderung ein Manifest verwenden, um die Reihenfolge der empfangenen Dateneinheiten zu bestimmen, und so den ursprünglichen Datenstrom wiederherstellen. Das Manifest kann eine Folge von Datensätzen enthalten, wobei jeder Datensatz einen bestimmten Satz von Dateneinheiten darstellt.
Die Datensätze des Manifests können ein oder mehrere Felder (hier auch als „Zeigerinformationen“ bezeichnet) enthalten, die Indizes identifizieren, die Speicherinformationen für die Dateneinheiten enthalten. Beispielsweise können die Speicherinformationen ein oder mehrere Indexfelder enthalten, die Informationen über den Speicherort (z. B. Container, Offsets usw.) für die gespeicherten Dateneinheiten, Komprimierungs- und/oder Verschlüsselungsmerkmale der gespeicherten Dateneinheiten usw. angeben. In einigen Beispielen können die Manifeste und Indizes jeweils in adressierbaren Abschnitten fester Größe (z.B. 4KB-Abschnitte) gelesen werden.
In einigen Beispielen kann das Deduplizierungssystem während der Verarbeitung eingehender Datenströme Datenobjekte im Speicher erzeugen und aktualisieren. Beispielsweise kann jeder Datenstrom mit Datencontainern, Manifesten (die die Reihenfolge der empfangenen Dateneinheiten angeben) und Container-Indizes (die Speicherinformationen wie Bezeichner von Datencontainern, Offsets usw. angeben) verknüpft sein. Solche Datenobjekte, die nur im Speicher vorhanden sind, können jedoch bei einem Stromausfall oder einem Systemfehler verloren gehen. Dementsprechend kann das Deduplizierungssystem zu verschiedenen Zeitpunkten während des Betriebs solche Datenobjekte aus dem Speicher in den permanenten Speicher schreiben (hier auch als „Persistieren“ jedes Objekts bezeichnet).
In einigen Beispielen kann ein herkömmlicher Prozess zur Persistierung von Datenobjekten eines eingehenden Datenstroms für jedes Manifest des eingehenden Datenstroms die Persistierung von mit dem Manifest verbundenen Datencontainern, dann die Persistierung von mit dem Manifest verbundenen Containerindizes und schließlich die Persistierung des Manifests selbst umfassen. Um die transaktionale Integrität der Datenobjekte zu gewährleisten, muss die Persistierung eines ersten Manifests und der zugehörigen Datenobjekte erfolgreich abgeschlossen sein, bevor mit der Persistierung eines anderen Manifests und der zugehörigen Datenobjekte fortgefahren wird. In Beispielen, die mehrere eingehende Datenströme umfassen, kann dasselbe Datenobjekt (z. B. ein bestimmter Containerindex) jedoch mehrfach persistiert werden (d. h. einmal für jeden eingehenden Datenstrom). Dementsprechend können solche konventionellen Persistenzoperationen doppelte und ineffiziente Schreibvorgänge in den persistenten Speicher beinhalten und somit zu relativ langsamen und/oder ineffizienten Deduplizierungsoperationen führen.
In Übereinstimmung mit einigen Implementierungen der vorliegenden Offenlegung kann ein Speichersystem einen Steuerprozess zur Verwaltung von Persistenzoperationen enthalten. Der Steuerprozess kann eine Anforderung für eine Persistenzoperation von einem Datenstromprozess empfangen und als Antwort ein Token an den Datenstromprozess liefern, anstatt die angeforderte Persistenzoperation auszuführen. In einigen Implementierungen kann das bereitgestellte Token einen Vertrag oder eine Verpflichtung darstellen oder damit verbunden sein, den angeforderten Schreibvorgang zu einem späteren Zeitpunkt durchzuführen (hier auch als „Persistenzvertrag“ bezeichnet). „Darüber hinaus kann der Stream-Prozess das Token anschließend verwenden, um die Persistenz-Operation abzuschließen.
In einigen Implementierungen können mehrere Token an mehrere Anforderer ausgegeben werden, wobei diese Token mehrere Persistenzverträge für ein einzelnes Datenobjekt (z. B. einen bestimmten Containerindex) darstellen. Wenn das Datenobjekt zu einem späteren Zeitpunkt persistiert wird, können die mehreren Persistenzverträge gleichzeitig durch einen einzigen Schreibvorgang erfüllt werden. Auf diese Weise kann das Speichersystem die Persistenz eines Datenobjekts gewährleisten und gleichzeitig die Anzahl der doppelten Schreibvorgänge für das Datenobjekt reduzieren. Dementsprechend können einige Implementierungen die Leistung des Speichersystems verbessern und die Menge an Rechenressourcen, die für die Persistenz der Daten benötigt werden, reduzieren.
1. Beispiel Speichersystem
zeigt ein Beispiel für ein Speichersystem 100, das einen Speicher-Controller 110, einen Speicher 115 und einen dauerhaften Speicher 140 gemäß einigen Implementierungen umfasst. Wie dargestellt, kann der dauerhafte Speicher 140 eine beliebige Anzahl von Manifesten 150, Containerindizes 160, Datencontainern 170 und Journalgruppen 120 enthalten. Ferner kann der Speicher 115 auch Manifeste 150, Containerindizes 160, Datencontainer 170, Journalgruppen 120 und einen Steuerprozess 180 enthalten. Der dauerhafte Speicher 140 kann ein oder mehrere nicht-übertragbare Speichermedien wie Festplattenlaufwerke (HDDs), Solid-State-Laufwerke (SSDs), optische Platten usw. oder eine Kombination davon umfassen. Der Speicher 115 kann in Form eines Halbleiterspeichers, z. B. eines Direktzugriffsspeichers (RAM), implementiert sein.
In einigen Implementierungen kann das Speichersystem 100 eine gleichzeitige Deduplizierung mehrerer eingehender Datenströme 105A-105N (hier auch als „Datenströme 105“ bezeichnet) durchführen. Zum Beispiel kann der Speicher-Controller 110 jeden Datenstrom 105 in Dateneinheiten unterteilen und mindestens eine Kopie jeder Dateneinheit in einem Datencontainer 170 speichern (z. B. durch Anhängen der Dateneinheiten an das Ende des Containers 170). In einigen Beispielen kann jeder Datencontainer 170 in Teile (hier auch als „Einheiten“ bezeichnet) unterteilt sein (in nicht dargestellt). Jede Einheit kann eine oder mehrere gespeicherte Dateneinheiten enthalten.
In einer oder mehreren Implementierungen kann die Speichersteuerung 110 einen Fingerabdruck für jede Dateneinheit erzeugen. Der Fingerabdruck kann zum Beispiel einen vollständigen oder teilweisen Hash-Wert auf der Grundlage der Dateneinheit enthalten. Um festzustellen, ob eine eingehende Dateneinheit ein Duplikat einer gespeicherten Dateneinheit ist, kann die Speichersteuerung 110 den für die eingehende Dateneinheit erzeugten Fingerabdruck mit den Fingerabdrücken der gespeicherten Dateneinheiten vergleichen. Ergibt dieser Vergleich eine Übereinstimmung, so kann die Speichersteuerung 110 feststellen, dass ein Duplikat der eingehenden Dateneinheit bereits im Speichersystem 100 gespeichert ist.
In einigen Implementierungen kann die Speichersteuerung 110 ein Manifest 150 erstellen, um die Reihenfolge aufzuzeichnen, in der die Dateneinheiten in jedem Datenstrom 105 empfangen wurden. Darüber hinaus kann das Manifest 150 einen Zeiger oder andere Informationen enthalten, die den Containerindex 160 angeben, der mit jeder Dateneinheit verbunden ist. In einigen Implementierungen kann der zugehörige Containerindex 160 den Ort angeben, an dem die Dateneinheit gespeichert ist. So kann der zugehörige Containerindex 160 beispielsweise Informationen enthalten, die angeben, dass die Dateneinheit an einem bestimmten Offset in einer Entität gespeichert ist und dass die Entität an einem bestimmten Offset in einem Datencontainer 170 gespeichert ist.
In einigen Implementierungen kann der Speicher-Controller 110 eine Leseanforderung für den Zugriff auf die gespeicherten Daten erhalten und daraufhin auf das Manifest 150 zugreifen, um die Reihenfolge der Dateneinheiten zu bestimmen, aus denen die ursprünglichen Daten bestehen. Die Speichersteuerung 110 kann dann die im Manifest 150 enthaltenen Zeigerdaten verwenden, um die den Dateneinheiten zugeordneten Containerindizes 160 zu identifizieren. Ferner kann der Speicher-Controller 110 die in den identifizierten Container-Indizes 160 enthaltenen Informationen verwenden, um die Speicherorte der Dateneinheiten zu bestimmen (z. B. Datencontainer 170, Entität, Offsets usw.), und kann dann die Dateneinheiten aus den bestimmten Speicherorten lesen.
In einigen Ausführungsformen kann jede Zeitschriftengruppe 120 mehrere Zeitschriften 130 enthalten. Jedes Journal 130 kann mit einem entsprechenden Index 160 verknüpft sein. In einigen Implementierungen kann ein Journal 130 im Speicher 115 Änderungen aufzeichnen, die mit den im zugehörigen Index 160 gespeicherten Metadaten verbunden sind. Wenn beispielsweise eine Kopie des Index 160 im Speicher 115 geändert wird, um eine Änderung der Metadaten widerzuspiegeln, kann diese Änderung auch als Eintrag in dem zugehörigen Journal 130 aufgezeichnet werden. In einigen Implementierungen kann jede Journalgruppe 120 einer einzelnen Datei oder einem einzelnen Objekt zugeordnet sein, das im Deduplizierungssystem gespeichert ist. Beispielsweise können die mehreren Journale 130, die in einer bestimmten Journalgruppe 120 enthalten sind, Indizes entsprechen, in denen Metadaten gespeichert sind, die zu einer einzigen Datei gehören.
In einigen Implementierungen kann das Speichersystem 100 einen Index 160 im Speicher 115 speichern, während auf Dateneinheiten zugegriffen wird, die mit diesem Index 160 verbunden sind. Beispielsweise kann der Index 160 im Speicher 115 gespeichert werden, während Dateneinheiten, die dem Index 160 zugeordnet sind, einem Datencontainer 170 hinzugefügt werden, aus dem Datencontainer 170 gelöscht werden und so weiter. Ferner kann der Speicher 115 auch eine Journalgruppe 120 speichern, die ein dem Index 160 entsprechendes Journal 130 enthält. In einigen Implementierungen kann das Journal 130 einen Satz von Änderungen aufzeichnen, die mit den im Index 160 gespeicherten Metadaten verbunden sind. Wenn beispielsweise der Index 160 im Speicher 115 geändert wird, um eine Änderung an den Metadaten wiederzugeben, kann diese Änderung auch im Journal 130 aufgezeichnet werden.
In einigen Implementierungen kann der Index 160 als Reaktion auf einen Befehl oder ein Ereignis geändert werden, um die im Journal 130 aufgezeichneten Änderungen aufzunehmen. Wenn beispielsweise ein Index 160 und das zugehörige Journal 130 in den Speicher 115 geladen werden (z. B. als Reaktion auf eine Leseanforderung), kann die Versionsnummer des Index 160 und des Journals 130 verglichen werden. Wenn die Versionsnummer des Journals 130 höher (d. h. neuer) ist als die Versionsnummer des Index 160, kann auf die im Index 160 aufgezeichneten Änderungen in chronologischer Reihenfolge (z. B. in der Reihenfolge des Auftretens) zugegriffen werden, und jede Änderung kann nacheinander im Index 160 durchgeführt werden. Andernfalls, wenn die Versionsnummer des Journals 130 nicht höher ist als die Versionsnummer des Index 160, kann das Journal 130 von allen aufgezeichneten Änderungen gelöscht werden, und das Journal 130 kann für die Aufzeichnung weiterer Änderungen verfügbar gemacht werden.
In einigen Implementierungen können Ereignisse, die zu Änderungen an den in einem Index 160 gespeicherten Metadaten führen, in einem mit dem Index 160 verbundenen Journal 130 aufgezeichnet werden. In einigen Beispielen kann, wenn die Anforderung besteht, den Index 160 in den permanenten Speicher 140 zu schreiben, bestimmt werden, ob der Füllstand des zugehörigen Journals 130 einen vordefinierten Schwellenwert überschreitet. Wenn der Füllstand den Schwellenwert nicht überschreitet, wird das Journal 130 in den dauerhaften Speicher 140 statt in den Index 160 geschrieben. Da das Journal 130 nur die jüngsten Änderungen am Index 160 aufzeichnet, kann das Schreiben des Journals 130 in den dauerhaften Speicher 140 relativ weniger Verarbeitungszeit und Bandbreite verbrauchen, als wenn der gesamte Index 160 in den dauerhaften Speicher 140 geschrieben würde.
In einer oder mehreren Implementierungen kann der Steuerprozess 180 eine Persistenzanforderung für einen Containerindex 160 im Speicher 115 empfangen und als Antwort ein Token für einen anfordernden Prozess bereitstellen. Das Token kann einen Vertrag zur Durchführung der angeforderten Persistenzoperation zu einem späteren Zeitpunkt darstellen. Die Verwendung von Token zur Darstellung von Persistenzverträgen wird weiter unten unter Bezugnahme auf die . Der Steuerungsprozess 180 kann von der Speichersteuerung 110 ausgeführt werden
2. Beispielhafte Datenstrukturen
zeigt ein Beispiel für Datenstrukturen 200, die bei der Deduplizierung in Übereinstimmung mit einigen Implementierungen verwendet werden. Wie dargestellt, können die Datenstrukturen 200 einen Manifestdatensatz 210, einen Containerindex 220, einen Container 250 und eine Entität 260 umfassen. In einigen Beispielen können der Manifestdatensatz 210, der Containerindex 220, der Container 250 und die Entität 230 im Allgemeinen den Beispielimplementierungen eines Manifestdatensatzes 155, eines Indexes 160, eines Datencontainers 170 bzw. einer Entität 175 (in dargestellt) entsprechen. In einigen Beispielen können die Datenstrukturen 200 von der Speichersteuerung 110 (in dargestellt) erzeugt und/oder verwaltet werden.
Wie in dargestellt, kann der Manifestdatensatz 210 in einigen Beispielen verschiedene Felder enthalten, wie z. B. Offset, Länge, Containerindex und Einheitsadresse. In einigen Ausführungsformen kann jeder Containerindex 220 eine beliebige Anzahl von Dateneinheitendatensätzen 230 und Entitätsdatensätzen 240 enthalten. Jeder Datensatz 230 kann verschiedene Felder enthalten, wie z. B. einen Fingerabdruck (z. B. einen Hash der Dateneinheit), eine Einheitsadresse, einen Entitätsidentifikator, einen Einheitsoffset (d. h. einen Offset der Dateneinheit innerhalb der Entität), einen Zählwert und eine Einheitslänge. Darüber hinaus kann jeder Entitätsdatensatz 240 verschiedene Felder enthalten, z. B. einen Entitätsbezeichner, einen Entitätsoffset (d. h. einen Offset der Entität innerhalb des Containers), eine gespeicherte Länge (d. h. eine Länge der Dateneinheit innerhalb der Entität), eine dekomprimierte Länge, einen Prüfsummenwert und Komprimierungs-/Verschlüsselungsinformationen (z. B. Art der Komprimierung, Art der Verschlüsselung und so weiter). In einigen Ausführungsformen kann jeder Container 250 eine beliebige Anzahl von Einheiten 260 enthalten, und jede Einheit 260 kann eine beliebige Anzahl von gespeicherten Dateneinheiten enthalten.
In einigen Implementierungen kann jeder Container-Index 220 eine Versionsnummer 235 enthalten, die eine Generation oder ein relatives Alter der Metadaten im Container-Index angibt. Die Versionsnummer 235 kann beispielsweise mit der Versionsnummer eines zugehörigen Journals verglichen werden (in nicht dargestellt). Wenn die Versionsnummer 235 größer ist als die Versionsnummer des zugehörigen Journals, kann festgestellt werden, dass der Container-Index 220 neuere Metadaten enthält als das zugehörige Journal.
In einer oder mehreren Implementierungen können die Datenstrukturen 200 verwendet werden, um gespeicherte deduplizierte Daten abzurufen. Beispielsweise kann eine Leseanforderung einen Versatz und eine Länge von Daten in einer bestimmten Datei angeben. Diese Anforderungsparameter können mit den Offset- und Längenfeldern eines bestimmten Manifestdatensatzes 210 abgeglichen werden. Der Containerindex und die Einheitsadresse des bestimmten Manifestdatensatzes 210 können dann mit einem bestimmten Dateneinheitsdatensatz 230 abgeglichen werden, der in einem Containerindex 220 enthalten ist. Ferner kann die Entitätskennung des bestimmten Datensatzes 230 mit der Entitätskennung eines bestimmten Entitätsdatensatzes 240 abgeglichen werden. Darüber hinaus können ein oder mehrere andere Felder des bestimmten Entitätsdatensatzes 240 (z. B. der Entitätsoffset, die gespeicherte Länge, die Prüfsumme usw.) zur Identifizierung des Behälters 250 und der Entität 260 verwendet werden, und die Dateneinheit kann dann aus dem identifizierten Behälter 250 und der Entität 260 gelesen werden.
3. Beispielhafte Datenstrukturen
zeigt eine Darstellung des Speichers 115 mit einer Journalgruppe 310 und mehreren Indizes 330. Wie dargestellt, umfasst die Journalgruppe 310 mehrere Journale 320. In einigen Beispielen können die Zapfengruppe 310, die Zapfen 320 und die Indizes 330 im Allgemeinen den Beispielimplementierungen der Zapfengruppe 120, der Zapfen 130 bzw. der Indizes 160 (dargestellt in ) entsprechen.
In einigen Implementierungen kann jedes Journal 320 mit einem entsprechenden Index 330 verbunden sein und Änderungen an den im entsprechenden Index 330 gespeicherten Metadaten aufzeichnen. Ferner können fürjede Journalgruppe 120 alle entsprechenden Indizes 330 mit einem einzigen gespeicherten Objekt (z. B. einem Dokument, einer Datenbanktabelle, einer Datendatei usw.) verknüpft sein. Beispielsweise können alle entsprechenden Indizes 330 Metadaten für Dateneinheiten enthalten, die in einer einzelnen Datei enthalten sind, die in einem Deduplizierungssystem gespeichert ist (z. B. das in dargestellte Speichersystem 100).
In einigen Implementierungen kann jedes Journal 320 eine Versionsnummer 325 enthalten oder mit ihr verbunden sein. Außerdem kann jeder Index 330 eine Versionsnummer 335 enthalten oder mit dieser verknüpft sein. In einigen Implementierungen kann die Versionsnummer 325 mit der Versionsnummer 335 verglichen werden, um festzustellen, ob die Zeitschrift 320 oder der zugehörige Index 330 die neueste Version der Metadaten enthält. Wenn beispielsweise die Versionsnummer 325 größer ist als die Versionsnummer 335, kann festgestellt werden, dass die im Journal 320 enthaltenen Änderungsdaten einen neueren Stand der Metadaten widerspiegeln als die im Index 330 gespeicherten Metadaten. Ist dies der Fall, kann der Index 330 aktualisiert werden, um die im Journal 320 aufgezeichneten Änderungen aufzunehmen. Wenn jedoch die Versionsnummer 325 kleiner ist als die Versionsnummer 335, kann festgestellt werden, dass die im Journal 320 enthaltenen Änderungsdaten einen Zustand der Metadaten widerspiegeln, der älter ist als die im Index 330 gespeicherten Metadaten. In diesem Fall kann das Journal 320 gelöscht werden, ohne den Index 330 zu aktualisieren. In einigen Implementierungen kann der Vergleich der Versionsnummer 325 mit der Versionsnummer 335 als Reaktion auf das Laden des Journals 320 oder des zugehörigen Index 330 aus dem Permanentspeicher in den Speicher (z. B. aus dem Permanentspeicher 140 in den Speicher 115, wie in dargestellt) durchgeführt werden. In einer oder mehreren Implementierungen kann die Anzahl der in einer Journalgruppe 310 enthaltenen Journale 320 in einem gespeicherten Parameter (z. B. einer Benutzereinstellung, einer Konfigurationsvariablen usw.) angegeben werden.
4. Beispielsystem
In ist ein Beispielsystem 400 gemäß einigen Implementierungen dargestellt. Wie gezeigt, kann das System 400 einen Speicher 415 und einen dauerhaften Speicher 440 umfassen. In einigen Beispielen können der Speicher 415 und der Permanentspeicher 440 im Allgemeinen den Beispielimplementierungen des Speichers 115 bzw. des Permanentspeichers 140 (dargestellt in ) entsprechen.
Wie dargestellt, kann der Speicher 415 mehrere Stream-Prozesse 410A-410N (hier auch als „Stream-Prozesse 410“ bezeichnet), mehrere Sätze von Datenobjekten 420A-420N (hier auch als „Datenobjekte 420“ bezeichnet) und eine Schreibsteuerung 430 enthalten. Jeder Stream-Prozess 410 kann ein Ausführungsprozess (z. B. ein Thread, ein Modul, eine Anwendung usw.) sein, der mit einem einzelnen Datenstrom verbunden ist. Beispielsweise kann jeder Datenstromprozess 410 von einem Prozessor (in nicht dargestellt) ausgeführt werden und die Deduplizierung eines zugehörigen Datenstroms auf der Grundlage externer Daten (z. B. Daten, die über ein Netzwerk von einer entfernten Quelle empfangen wurden) oder lokaler Daten (z. B. eine Datei oder andere Daten, die in dem permanenten Speicher 440 gespeichert sind) verwalten. Wie in dargestellt, kann jeder Stream-Prozess 410 einen entsprechenden Satz von Datenobjekten 420 erzeugen und/oder aktualisieren. Jeder Satz von Datenobjekten 420 kann Manifeste 422, Container-Indizes 424, Journale 426 und Datencontainer 428 enthalten. In einigen Implementierungen kann jedes Journal 426 mit einem bestimmten Containerindex 424 verbunden sein.
In einigen Implementierungen kann die Schreibsteuerung 430 ein Ausführungsprozess sein, der Schreibvorgänge der Datenobjekte 420 aus dem Speicher 415 in den persistenten Speicher 440 verwaltet (hier auch als „Persistenzvorgänge“ bezeichnet). Beispielsweise kann die Schreibsteuerung 430 eine Persistenzanforderung von einem Stream-Prozess 410 empfangen und als Antwort ein Token an den Stream-Prozess 410 senden. Das Token kann einen Vertrag zur Durchführung der angeforderten Persistenzoperation zu einem späteren Zeitpunkt darstellen. In einigen Beispielen kann die Schreibsteuerung 430 im Allgemeinen einer Beispielimplementierung des Steuerungsprozesses 180 (wie in dargestellt) entsprechen.
In einigen Implementierungen können mehrere Stream-Prozesse 410 dasselbe Datenobjekt 420 (z. B. einen bestimmten Container-Index 424) verwenden und separat Persistenzanforderungen für dasselbe Datenobjekt 420 an die Schreibsteuerung 430 senden. Anstatt die angeforderten Persistenzoperationen auszuführen, kann die Schreibsteuerung 430 den anfordernden Stream-Prozessen 410 verschiedene Token zur Verfügung stellen, die Persistenzverträge für dasselbe Datenobjekt 420 darstellen. Zu einem späteren Zeitpunkt kann die Schreibsteuerung 430 das Datenobjekt 420 persistieren, indem sie einen einzigen Schreibvorgang vom Speicher 415 in den persistenten Speicher 440 durchführt. Außerdem können die mehreren Persistenzverträge (die durch die mehreren Token dargestellt werden) durch diesen einzigen Schreibvorgang erfüllt werden.
In einigen Implementierungen kann jedes Token ein eindeutiger Bezeichner sein, der einen Persistenzvertrag darstellt, aber für den Stream-Prozess 410 „undurchsichtig“ ist (d. h. vom Stream-Prozess 410 nicht gelesen oder geparst werden kann, um spezifische Informationen über den zugehörigen Vertrag zu ermitteln). So kann die Schreibsteuerung 430 beispielsweise jedes Token als zufällige Zeichenfolge aus alphanumerischen Zeichen erzeugen. Darüber hinaus kann die Schreibsteuerung 430 eine Vertragsdatenstruktur 435 enthalten, um Informationen über die den Stream-Prozessen 410 bereitgestellten Token und die zugehörigen Persistenzverträge zu verfolgen. Beispielsweise kann die Vertragsdatenstruktur 435 jedes Token, den Stream-Prozess 410, der das Token erhalten hat, das zu persistierende Datenobjekt, den aktuellen Status der Persistenzoperation usw. verfolgen. Ein Beispiel für einen Vorgang, der die Token und die Vertragsdatenstruktur 435 verwendet, wird im Folgenden unter Bezugnahme auf beschrieben.
In einigen Implementierungen kann die Schreibsteuerung 430 jedes Datenobjekt 420 persistieren, indem sie zunächst ein Token ausgibt, das einen Persistenzvertrag darstellt, und anschließend den durch das Token dargestellten Persistenzvertrag vervollständigt oder „erfüllt“ (hier auch als „Vervollständigung des Tokens“ bezeichnet). In einigen Beispielen kann die Schreibsteuerung 430 das Token als Antwort auf eine Persistenzanforderung von einem Stream-Prozess 410 ausgeben.
In einigen Implementierungen kann die Schreibsteuerung 430 das Token in Reaktion auf eine Token-Abschlussanforderung von einem Stream-Prozess 410 abschließen. Bei der Token-Abschlussanforderung kann es sich beispielsweise um einen Flush-Befehl handeln, der vom Stream-Prozess 410 als Reaktion auf das Erreichen des Endpunkts oder eines Kontrollpunkts eines eingehenden Datenstroms erzeugt wird. In einigen Beispielen kann die Abschlussanforderung das Token enthalten (z. B. als Parameter, abgelegt usw.). Darüber hinaus kann die Schreibsteuerung 430 in einigen Implementierungen das Token als Reaktion auf ein Ereignis oder eine Bedingung vervollständigen, das/die im System 400 auftritt (hier auch als „Systemereignisse“ bezeichnet). Beispielsweise kann ein Container-Index 424 im Speicher gemäß einer LRU-Richtlinie (Least Recently Used) zur Räumung ausgewählt werden (z. B. wenn der für die Container-Indizes 424 zugewiesene Speicherplatz voll ist), und als Reaktion darauf kann die Schreibsteuerung 430 veranlassen, dass der ausgewählte Container-Index in den persistenten Speicher geschrieben wird. Auf diese Weise kann ein Persistenzvertrag für den ausgewählten Containerindex 424 durch das Systemereignis „Räumung“ erfüllt werden.
In einer oder mehreren Implementierungen kann der durch ein Token dargestellte Persistenzvertrag mit einer Kombination aus einem bestimmten Container-Index 424 und seiner Versionsnummer verbunden sein. Wenn beispielsweise ein erster Container-Index C1 zu dem Zeitpunkt, zu dem ein erstes Token erzeugt wird, eine erste Versionsnummer V1 hat, dann kann das erste Token einen Vertrag zur Persistenz einer Kopie des ersten Container-Index C1 mit der ersten Versionsnummer V1 darstellen. In einem anderen Beispiel kann, wenn der erste Container-Index C1 zu einem späteren Zeitpunkt, zu dem ein zweites Token erzeugt wird, eine zweite Versionsnummer V2 hat, das zweite Token einen Vertrag darstellen, eine Kopie des ersten Container-Index C1 mit der zweiten Versionsnummer V2 aufrechtzuerhalten. Ferner kann in einigen Implementierungen die Versionsnummer des Container-Index 424 als Reaktion auf eine Persistenzoperation, die den Container-Index 424 mit einer ersten Versionsnummer (z. B. V1) schreibt, erhöht werden (z. B. auf V2).
In einigen Implementierungen kann ein Token, das einen Vertrag zur Aufrechterhaltung eines Containerindex 424 darstellt, so geändert werden, dass es stattdessen einen Vertrag zur Aufrechterhaltung eines mit dem Containerindex 424 verbundenen Journals 426 darstellt. Beispielsweise kann die Schreibsteuerung 430 (oder ein anderes Steuermodul) feststellen, dass der für die Container-Indizes 424 zugewiesene Speicherplatz einen Schwellenwert überschritten hat, und kann daher veranlassen, dass ein erstes Journal 426 anstelle eines zugehörigen Container-Index 424 verwendet wird (d. h. zur Aufzeichnung von Metadatenänderungen für einen eingehenden Stream). Außerdem kann die Schreibsteuerung 430 einen bestehenden Vertrag zur Aufrechterhaltung des Containerindex 424 ändern, um stattdessen das erste Journal 426 aufrechtzuerhalten. Darüber hinaus kann die Schreibsteuerung 430 Verträge zur Aufrechterhaltung von Journalen 426 modifizieren, um stattdessen die zugehörigen Container-Indizes 424 aufrechtzuerhalten. In einigen Implementierungen können solche Vertragsänderungen von der Schreibsteuerung 430 vorgenommen und nachverfolgt werden, sie können jedoch vor den Stream-Prozessen 410, die die Token empfangen, verborgen bleiben.
5. Beispielbetrieb
zeigt ein Beispiel für einen Vorgang 500 in Übereinstimmung mit einigen Implementierungen. Wie dargestellt, umfasst der Beispielvorgang 500 den Datenfluss und/oder Aktionen für drei Prozesse, nämlich StreamA 502, Schreibsteuerung 504 und StreamB 506. Bei StreamA 502 und StreamB 506 kann es sich um Streaming-Prozesse handeln, die von einem Prozessor (z. B. dem in gezeigten Speicher-Controller 110) ausgeführt werden. Außerdem ist die Schreibsteuerung 504 ein vom Prozessor ausgeführter Schreibsteuerungsprozess. Nehmen wir an, dass in der Abbildung in verschiedene Zeitpunkte an verschiedenen vertikalen Positionen dargestellt sind, wobei die relativ höheren vertikalen Positionen frühere Zeitpunkte und die relativ höheren unteren Positionen spätere Zeitpunkte darstellen.
Zu dem in gezeigten frühesten Zeitpunkt kann StreamA 502 eine Anforderung 510 zur Aufrechterhaltung eines ersten Container-Index C1 senden. Angenommen, der erste Containerindex C1 hat zu diesem Zeitpunkt eine Versionsnummer V1 (z. B. entsprechend der Versionsnummer 235 in ). Dementsprechend kann die Schreibsteuerung 504 als Reaktion auf die Anforderung 510 ein Token1(C1,V1) an StreamA 502 liefern. Wie hier verwendet, bezieht sich die Bezeichnung „Token1(C1,V1)“ auf ein erstes Token, das einen Persistenzvertrag für einen Containerindex C1 mit einer Versionsnummer V1 darstellt. Nehmen wir an, dass in der Beispieloperation 500 der erste Containerindex C1 als Antwort auf die Anfrage 510 nicht persistiert wird.
Zu einem späteren Zeitpunkt kann StreamB 506 eine Anforderung 520 senden, um den ersten Containerindex C1 beizubehalten. Dementsprechend kann die Schreibsteuerung 504 als Reaktion auf die Anforderung 520 ein Token2(C1,V1) an StreamB 506 liefern. Außerdem kann StreamA 502 eine Anforderung 530 senden, um einen zweiten Container-Index C2 aufrechtzuerhalten. Nehmen wir an, dass der zweite Containerindex C2 zu diesem Zeitpunkt eine Versionsnummer V1 hat. Dementsprechend kann die Schreibsteuerung 504 als Antwort auf die Anforderung 530 ein Token3(C2,V1) an StreamA 502 übermitteln (535). Nehmen wir an, dass in der Beispieloperation 500 der erste Containerindex C1 als Reaktion auf die Anforderung 520 nicht persistiert wird und der zweite Containerindex C2 als Reaktion auf die Anforderung 530 nicht persistiert wird.
Zu einem späteren Zeitpunkt kann StreamB 506 eine Anfrage 540 zur Vervollständigung des Token2(C1,V1) senden. Wie hier verwendet, bezieht sich die Formulierung „das Token vervollständigen“ auf die Erfüllung des durch das Token repräsentierten Persistenzvertrags. Als Antwort auf die Anforderung 540 kann die Schreibsteuerung 504 den ersten Containerindex C1 per Token2(C1,V1) schreiben. Anders ausgedrückt: Die Schreibsteuerung 504 kann das Token2(C1,V1) vervollständigen, indem sie die Version V1 des ersten Containerindex C1 in den persistenten Speicher schreibt. Ferner kann die Schreibsteuerung 504 als Reaktion auf das Schreiben des ersten Containerindex C1 in den dauerhaften Speicher die Versionsnummer des ersten Containerindex C1 von V1 auf V2 erhöhen. Darüber hinaus kann die Schreibsteuerung 504 nach dem Schreiben des ersten Containerindex C1 in den permanenten Speicher eine Bestätigung 546 an StreamB 506 senden, dass das Token2(C1,V1) abgeschlossen wurde.
Zu einem späteren Zeitpunkt kann die Schreibsteuerung 504 den zweiten Containerindex C2 durch ein Systemereignis beschreiben. Wenn beispielsweise der für Containerindizes zugewiesene Speicherplatz voll ist, kann ein LRU-Prozess (Least Recently Used) den zweiten Containerindex C2 als aus dem Speicher zu entfernen bestimmen. Dementsprechend kann die Schreibsteuerung 504 den zweiten Containerindex C2 in den permanenten Speicher schreiben, um den Verlust von Indexinformationen zu vermeiden, wenn der zweite Containerindex C2 aus dem Speicher entfernt wird. Ferner kann die Schreibsteuerung 504 als Reaktion auf das Schreiben des zweiten Containerindex C2 in den permanenten Speicher die Versionsnummer des zweiten Containerindex C2 von V1 auf V2 erhöhen.
Zu einem späteren Zeitpunkt kann StreamA 502 eine Anforderung 560 senden, um den ersten Container-Index C1 beizubehalten. Es sei daran erinnert, dass die Versionsnummer des ersten Container-Index C1 auf V2 erhöht wurde (d. h. in Feld 542). Dementsprechend kann die Schreibsteuerung 504 als Reaktion auf die Anforderung 560 ein Token4(C1,V2) an StreamA 502 liefern.
Zu einem späteren Zeitpunkt kann StreamA 502 eine Anfrage 570 senden, um Token1(C1,V1), Token3(C2,V1) und Token4(C1,V2) abzuschließen. Als Reaktion auf die Anforderung 570 kann die Schreibsteuerung 504 gespeicherte Vertragsdaten lesen (z. B. die in gezeigten Vertragsdaten 435) und dabei feststellen, dass Token1(C1,V1) und Token3(C2,V1) zuvor abgeschlossen wurden. Insbesondere wurde Token1(C1,V1) bereits abgeschlossen, als der erste Containerindex C1 in Token2(C1,V1) geschrieben wurde (d.h. in Feld 542). Ferner wurde Token3(C2,V1) zuvor abgeschlossen, als der zweite Containerindex C2 per Systemereignis geschrieben wurde (d. h. in Feld 550). Dementsprechend kann die Schreibsteuerung 504 den ersten Containerindex C1 per Token4(C1,V2) 572 schreiben. Anders ausgedrückt: Die Schreibsteuerung 504 kann das Token4(C1,V2) abschließen, indem sie die Version V2 des ersten Containerindex C1 in den permanenten Speicher schreibt. Ferner kann die Schreibsteuerung 504 als Reaktion auf das Schreiben des ersten Containerindex C1 in den dauerhaften Speicher die Versionsnummer des ersten Containerindex C1 von V2 auf V3 erhöhen. Außerdem kann die Schreibsteuerung 504 eine Bestätigung 576 an StreamA 502 senden, dass Token1(C1,V1), Token3(C2,V1) und Token4(C1,V2) abgeschlossen wurden.
6. Beispiel einer Vertragsdatenstruktur
zeigt ein Beispiel für eine Vertragsdatenstruktur 600 in Übereinstimmung mit einigen Implementierungen. In einigen Beispielen kann die Vertragsdatenstruktur 600 im Allgemeinen einer Beispielimplementierung der Vertragsdaten 435 entsprechen, die mit der Schreibsteuerung 430 verbunden sind (in dargestellt). Wie in dargestellt, kann die Vertragsdatenstruktur 600 eine beliebige Anzahl von Einträgen enthalten, die verschiedenen Token entsprechen. In einigen Implementierungen kann ein Schreibsteuerungsprozess die Vertragsdatenstruktur 600 verwenden, um durch ausgegebene Token dargestellte Persistenzverträge zu verfolgen und zu ändern.
In einigen Implementierungen kann jeder Eintrag der Vertragsdatenstruktur 600 eine beliebige Anzahl von Datenfeldern enthalten, die sich auf ein bestimmtes Token beziehen. Wie in dargestellt, kann jeder Eintrag beispielsweise einen Token-Wert, eine Kundenkennung, eine Objektkennung, eine Versionsnummer und/oder ein Statusfeld enthalten. In einigen Beispielen kann der Token-Wert eine eindeutige alphanumerische Zeichenfolge sein. Die Client-Kennung kann einen Prozess identifizieren (z. B. den in dargestellten Stream-Prozess StreamA 502), der das Token empfängt (z. B. als Antwort auf eine Persistenzanforderung).
In einigen Implementierungen können der Objektidentifikator und die Versionsnummer das Datenobjekt und seine Version identifizieren (z. B. einen Container-Index 424 oder ein zugehöriges Journal 426, wie in gezeigt), das durch den Vertrag, der durch das Token repräsentiert wird, aufrechterhalten wird. Das Statusfeld kann einen Status des Vertrags angeben (z. B. nicht erfüllt, bereits erfüllt, abgeschlossen usw.).
In einer oder mehreren Implementierungen kann der Objektidentifikator eines Eintrags aktualisiert werden, wenn der durch den Eintrag repräsentierte Vertrag geändert wird, um ein anderes Datenobjekt aufrechtzuerhalten. Wenn beispielsweise ein Eintrag ursprünglich mit einem Vertrag zur Aufrechterhaltung eines Containerindexes verknüpft ist und der Vertrag geändert wird, um stattdessen ein Journal aufrechtzuerhalten, kann der Objektidentifikator dieses Eintrags aktualisiert werden, um das Journal anstelle des Containerindexes zu identifizieren. In einigen Beispielen kann ein Schreibsteuerungsprozess (oder ein anderer Steuerungsprozess) feststellen, dass der für die Container-Indizes zugewiesene Speicherplatz einen Schwellenwert überschritten hat, und kann daher veranlassen, dass ein erstes Journal anstelle eines zugehörigen Container-Index verwendet wird (d. h. zur Aufzeichnung von Metadatenänderungen für einen eingehenden Datenstrom). Darüber hinaus kann der Schreibsteuerungsprozess einen bestehenden Vertrag zur Aufrechterhaltung des Containerindexes ändern, um stattdessen das erste Journal aufrechtzuerhalten.
7. Beispielprozess für das Capping von Trackingdaten in einem Containerindex
zeigt ein Beispiel für einen Prozess 700 zur Änderung eines Vertrags in Übereinstimmung mit einigen Implementierungen. In einigen Beispielen kann der Prozess 700 durchgeführt werden, um einen Vertrag zur Aufrechterhaltung einer Art von Datenobjekt zu ändern und stattdessen eine andere Art von Objekt aufrechtzuerhalten. Der Prozess 700 kann unter Verwendung des Speicher-Controllers 110 (in dargestellt) durchgeführt werden. Der Prozess 700 kann in Hardware oder einer Kombination aus Hardware und Programmierung (z. B. maschinenlesbare Anweisungen, die von einem oder mehreren Prozessoren ausgeführt werden können) implementiert werden. Die maschinenlesbaren Anweisungen können in einem nicht-transitorischen, computerlesbaren Medium gespeichert werden, z. B. in einem optischen, Halbleiter- oder magnetischen Speichergerät. Die maschinenlesbaren Anweisungen können von einem einzigen Prozessor, mehreren Prozessoren, einer einzigen Verarbeitungsmaschine, mehreren Verarbeitungsmaschinen usw. ausgeführt werden. Zur Veranschaulichung werden im Folgenden Einzelheiten des Verfahrens 700 unter Bezugnahme auf die beschrieben, die Beispiele für einige Implementierungen zeigen. Es sind jedoch auch andere Implementierungen möglich.
Block 710 kann den Empfang einer Anforderung von einem Stream-Prozess beinhalten, einen Container-Index aus dem Speicher in den permanenten Speicher zu schreiben. Block 720 kann die Erzeugung eines Vertrags und das Senden eines Tokens an den Stream-Prozess umfassen. Wie in dargestellt, kann die Schreibsteuerung 430 beispielsweise vom Datenstromprozess 410A eine Anforderung empfangen, einen Containerindex 424 zu persistieren. Als Antwort darauf kann die Schreibsteuerung 430 ein Token an den Stream-Prozess 410A senden, wobei das Token einen Vertrag zur Aufrechterhaltung des Container-Index 424 darstellt.
Block 730 kann die Feststellung beinhalten, dass der für Container-Indizes zugewiesene Speicherplatz einen Schwellenwert überschreitet. Block 740 kann die Änderung des Vertrags beinhalten, um stattdessen ein Journal zu schreiben, das mit dem Container-Index verbunden ist. Beispielsweise kann die Schreibsteuerung 430 (oder ein anderes Steuermodul) unter Bezugnahme auf feststellen, dass der für den Containerindex 424 zugewiesene Speicherplatz einen Schwellenwert überschritten hat, und daraufhin den Vertrag modifizieren, um stattdessen ein mit dem Containerindex 424 verbundenes Journal 426 aufrechtzuerhalten. Nach Block 740 kann der Prozess 700 beendet werden.
8. Beispielprozess für die Persistierung eines Containerindexes
In ist ein Beispielprozess 800 für die Aufrechterhaltung eines Containerindexes in Übereinstimmung mit einigen Implementierungen dargestellt. In einigen Beispielen kann der Prozess 800 unter Verwendung des Speicher-Controllers 110 (dargestellt in ) durchgeführt werden. Der Prozess 800 kann in Hardware oder einer Kombination aus Hardware und Programmierung (z. B. maschinenlesbare Anweisungen, die von einem oder mehreren Prozessoren ausgeführt werden können) implementiert werden. Die maschinenlesbaren Anweisungen können in einem nicht-transitorischen, computerlesbaren Medium gespeichert werden, z. B. in einem optischen, Halbleiter- oder magnetischen Speichergerät. Die maschinenlesbaren Anweisungen können von einem einzigen Prozessor, mehreren Prozessoren, einer einzigen Verarbeitungsmaschine, mehreren Verarbeitungsmaschinen usw. ausgeführt werden. Zur Veranschaulichung werden Einzelheiten des Prozesses 800 im Folgenden unter Bezugnahme auf die beschrieben, die Beispiele für einige Implementierungen zeigen. Es sind jedoch auch andere Implementierungen möglich.
Block 810 kann beinhalten, dass von einem ersten Stream-Prozess eine erste Schreibanforderung für einen ersten Container-Index im Speicher empfangen wird. Block 820 kann als Reaktion auf den Empfang der ersten Schreibanforderung das Senden eines ersten Tokens an den ersten Stream-Prozess beinhalten, ohne den ersten Container-Index in einen dauerhaften Speicher zu schreiben. Beispielsweise kann die Schreibsteuerung 504 eine Anforderung 520 vom Stream-Prozess StreamB 506 empfangen, um einen ersten Container-Index C1 zu persistieren. Als Antwort darauf kann die Schreibsteuerung 504 ein Token2(C1,V1) an StreamB 506 liefern (525).
Block 830 kann den Empfang einer ersten Abschlussanforderung für den ersten Containerindex von einem zweiten Stream-Prozess beinhalten. Block 840 kann als Reaktion auf den Empfang der ersten Vervollständigungsanforderung das Schreiben des ersten Containerindex aus dem Speicher in den permanenten Speicher umfassen. Beispielsweise kann die Schreibsteuerung 504 eine Anforderung 540 zur Vervollständigung von Token2(C1,V1) von StreamB 506 erhalten (siehe ). Als Antwort darauf kann die Schreibsteuerung 504 die Version V1 des ersten Containerindex C1 in den Permanentspeicher schreiben (542). Nach Block 840 kann der Prozess 800 beendet werden.
9. Beispiel für ein maschinenlesbares Medium
zeigt ein maschinenlesbares Medium 900, auf dem Anweisungen 910-940 in Übereinstimmung mit einigen Implementierungen gespeichert sind. Die Anweisungen 910-940 können von einem einzigen Prozessor, mehreren Prozessoren, einer einzigen Verarbeitungsmaschine, mehreren Verarbeitungsmaschinen usw. ausgeführt werden. Das maschinenlesbare Medium 900 kann ein nicht-transitorisches Speichermedium sein, wie z. B. ein optisches, Halbleiter- oder magnetisches Speichermedium.
Die Anweisung 910 kann ausgeführt werden, um von einem ersten Stromprozess eine erste Schreibanforderung für einen ersten Containerindex im Speicher zu empfangen. Die Anweisung 920 kann ausgeführt werden, um als Reaktion auf den Empfang der ersten Schreibanforderung ein erstes Token an den ersten Stream-Prozess zu senden, ohne den ersten Container-Index in einen dauerhaften Speicher zu schreiben. Die Anweisung 930 kann ausgeführt werden, um von einem zweiten Datenstromprozess eine erste Abschlussanforderung für den ersten Containerindex zu empfangen. Die Anweisung 940 kann ausgeführt werden, um als Reaktion auf den Empfang der ersten Vervollständigungsanforderung den ersten Containerindex aus dem Speicher in den dauerhaften Speicher zu schreiben.
10. Beispiel für ein Datenverarbeitungsgerät
zeigt ein schematisches Diagramm einer beispielhaften Rechenvorrichtung 1000. In einigen Beispielen kann die Rechenvorrichtung 1000 im Allgemeinen einem Teil oder der Gesamtheit des Speichersystems 100 (dargestellt in ) entsprechen. Wie dargestellt, kann die Rechenvorrichtung 1000 einen Hardware-Prozessor 1002 und einen maschinenlesbaren Speicher 1005 mit Anweisungen 1010-1040 enthalten. Der maschinenlesbare Speicher 1005 kann ein nicht-übertragbares Medium sein. Die Anweisungen 1010-1040 können durch den Hardware-Prozessor 1002 oder durch eine im Hardware-Prozessor 1002 enthaltene Verarbeitungsmaschine ausgeführt werden.
Die Anweisung 1010 kann ausgeführt werden, um von einem ersten Stromprozess eine erste Schreibanforderung für einen ersten Containerindex im Speicher zu empfangen. Die Anweisung 1020 kann ausgeführt werden, um als Reaktion auf den Empfang der ersten Schreibanforderung ein erstes Token an den ersten Stream-Prozess zu senden, ohne den ersten Container-Index in einen dauerhaften Speicher zu schreiben. Die Anweisung 1030 kann ausgeführt werden, um von einem zweiten Stromprozess eine erste Abschlussanforderung für den ersten Containerindex zu empfangen. Die Anweisung 1040 kann ausgeführt werden, um als Reaktion auf den Empfang der ersten Vervollständigungsanforderung den ersten Containerindex aus dem Speicher in den dauerhaften Speicher zu schreiben.
In Übereinstimmung mit den hier beschriebenen Implementierungen kann ein Speichersystem einen Steuerprozess zur Verwaltung von Persistenzoperationen enthalten. Der Steuerprozess kann eine Anforderung für eine Persistenzoperation von einem Stream-Prozess empfangen und als Antwort ein Token an den Stream-Prozess liefern, anstatt die angeforderte Persistenzoperation durchzuführen. In einigen Implementierungen kann das bereitgestellte Token einen Vertrag über die Durchführung des angeforderten Schreibvorgangs zu einem späteren Zeitpunkt darstellen. Außerdem kann der Stream-Prozess das Token anschließend verwenden, um den Persistenzvorgang abzuschließen. Mithilfe solcher Token kann das Speichersystem ein Datenobjekt aufrechterhalten und gleichzeitig die Anzahl der doppelten Schreibvorgänge für das Datenobjekt verringern. Dementsprechend können einige Implementierungen die Leistung des Speichersystems verbessern und die Menge an Rechenressourcen, die für die Datenpersistenz benötigt werden, reduzieren.
Beachten Sie, dass die verschiedene Beispiele zeigen, sind die Implementierungen in dieser Hinsicht nicht beschränkt. Beispielsweise kann das Speichersystem 100, wie in dargestellt, zusätzliche Geräte und/oder Komponenten, weniger Komponenten, andere Komponenten, andere Anordnungen usw. enthalten. Ein weiteres Beispiel ist, dass die oben beschriebene Funktionalität des Speicher-Controllers 110 in einer anderen Maschine oder Software des Speichersystems 100 enthalten sein kann. Andere Kombinationen und/oder Variationen sind ebenfalls möglich.
Daten und Anweisungen werden in entsprechenden Speichervorrichtungen gespeichert, die als ein oder mehrere computerlesbare oder maschinenlesbare Speichermedien ausgeführt sind. Zu den Speichermedien gehören verschiedene Formen von nicht transitorischen Speichern, darunter Halbleiterspeicher wie dynamische oder statische Direktzugriffsspeicher (DRAMs oder SRAMs), löschbare und programmierbare Festwertspeicher (EPROMs), elektrisch löschbare und programmierbare Festwertspeicher (EEPROMs) und Flash-Speicher; Magnetplatten wie Fest-, Disketten- und Wechselplatten; andere magnetische Medien einschließlich Bänder; optische Medien wie Compact Discs (CDs) oder digitale Videodisks (DVDs) oder andere Arten von Speichervorrichtungen.
Es ist zu beachten, dass die oben erörterten Anweisungen auf einem einzigen computerlesbaren oder maschinenlesbaren Speichermedium oder alternativ auf mehreren computerlesbaren oder maschinenlesbaren Speichermedien bereitgestellt werden können, die in einem großen System mit möglicherweise mehreren Knotenpunkten verteilt sind. Ein solches computerlesbares oder maschinenlesbares Speichermedium oder solche Speichermedien werden als Teil eines Artikels (oder eines Herstellungsartikels) betrachtet. Ein Artikel oder Herstellungsgegenstand kann sich auf jede hergestellte Einzelkomponente oder mehrere Komponenten beziehen. Das Speichermedium oder die Speichermedien können sich entweder in der Maschine befinden, auf der die maschinenlesbaren Anweisungen ausgeführt werden, oder an einem entfernten Standort, von dem maschinenlesbare Anweisungen über ein Netzwerk zur Ausführung heruntergeladen werden können.
In der vorstehenden Beschreibung werden zahlreiche Details aufgeführt, um ein Verständnis des hierin offengelegten Themas zu vermitteln. Allerdings können Implementierungen ohne einige dieser Details praktiziert werden. Andere Implementierungen können Modifikationen und Abweichungen von den oben beschriebenen Details enthalten. Es ist beabsichtigt, dass die beigefügten Ansprüche solche Modifikationen und Variationen abdecken.

Claims

Ein Verfahren, das Folgendes umfasst: Empfang einer ersten Schreibanforderung für einen ersten Container-Index im Speicher von einem ersten Stream-Prozess; als Reaktion auf den Empfang der ersten Schreibanforderung, Senden eines ersten Tokens an den ersten Stream-Prozess, ohne den ersten Container-Index in einen dauerhaften Speicher zu schreiben; Empfangen einer ersten Beendigungsanforderung für den ersten Containerindex von einem zweiten Stromprozess; und als Reaktion auf den Empfang der ersten Erledigungsanforderung, Schreiben des ersten Containerindexes aus dem Speicher in den Permanentspeicher.
Das Verfahren nach Anspruch 1, bei dem vor dem Empfang der ersten Beendigungsanforderung von dem zweiten Datenstromprozess: Empfangen einer zweiten Schreibanforderung für den ersten Container-Index im Speicher durch den zweiten Stream-Prozess; als Reaktion auf den Empfang der zweiten Schreibanforderung, Senden eines zweiten Tokens an den zweiten Stream-Prozess, ohne den ersten Container-Index in den permanenten Speicher zu schreiben.
Das Verfahren nach Anspruch 2, umfassend: nach dem Schreiben des ersten Containerindexes in den persistenten Speicher, Senden einer ersten Schreibbestätigung an den zweiten Stream-Prozess, wobei die erste Schreibbestätigung mit dem zweiten Token verbunden ist.
Das Verfahren nach Anspruch 3, bei dem nach dem Senden der ersten Schreibbestätigung an den zweiten Stromprozess Empfangen einer zweiten Beendigungsanforderung für den ersten Container-Index von dem ersten Stream-Prozess; als Reaktion auf den Empfang der zweiten Vervollständigungsanforderung die Feststellung, dass der erste Containerindex zuvor in den Dauerspeicher geschrieben wurde; und als Reaktion auf die Feststellung, dass der erste Containerindex zuvor in den Permanentspeicher geschrieben wurde, Senden einer zweiten Schreibbestätigung an den ersten Stream-Prozess, wobei die zweite Schreibbestätigung mit dem ersten Token verknüpft ist.
Das Verfahren nach Anspruch 4, wobei die erste Abschlussanforderung das zweite Token enthält, das an den zweiten Stream-Prozess gesendet wird, und wobei die zweite Abschlussanforderung das erste Token enthält, das an den ersten Stream-Prozess gesendet wird.
Das Verfahren nach Anspruch 2, umfassend: Empfangen einer dritten Schreibanforderung für einen zweiten Container-Index im Speicher durch den ersten Stream-Prozess; als Reaktion auf den Empfang der dritten Schreibanforderung ein drittes Token an den ersten Stromprozess zu senden, wobei das dritte Token mit einem ersten Vertrag zur Aufrechterhaltung des zweiten Containerindex verbunden ist.
Das Verfahren nach Anspruch 6, umfassend: Erfassen einer Speicherbedingung, die mit dem zweiten Behälterindex verbunden ist; und als Reaktion auf die Erkennung der Speicherbedingung, Änderung des ersten Vertrages, um ein Journal anstelle des zweiten Containerindexes aufrechtzuerhalten.
Das Verfahren nach Anspruch 7, wobei das Modifizieren des ersten Vertrags das Aktualisieren eines ersten Eintrags einer Vertragsdatenstruktur umfasst, wobei der erste Eintrag mit dem dritten Token verbunden ist.
Das Verfahren nach Anspruch 6, umfassend: Erkennen einer anstehenden Räumung des zweiten Containerindexes aus dem Speicher; und als Reaktion auf die Erkennung der anstehenden Räumung, Schreiben des zweiten Containerindexes aus dem Speicher in den Permanentspeicher.
Ein nicht-transitorisches maschinenlesbares Medium, das Befehle speichert, die bei Ausführung einen Prozessor dazu veranlassen: von einem ersten Stream-Prozess eine erste Schreibanforderung für einen ersten Container-Index im Speicher empfangen; als Reaktion auf den Empfang der ersten Schreibanforderung ein erstes Token an den ersten Stream-Prozess senden, ohne den ersten Container-Index in einen dauerhaften Speicher zu schreiben; von einem zweiten Stromprozess eine erste Beendigungsanforderung für den ersten Containerindex empfangen; und als Reaktion auf den Empfang der ersten Abschlussanforderung den ersten Containerindex aus dem Speicher in den Permanentspeicher zu schreiben.
Das nicht-transitorische maschinenlesbare Medium nach Anspruch 10, das Anweisungen enthält, die bei der Ausführung den Prozessor veranlassen, vor dem Empfang der ersten Beendigungsanforderung von dem zweiten Stromprozess: vom zweiten Stromprozess eine zweite Schreibanforderung für den ersten Containerindex im Speicher empfangen; als Reaktion auf den Empfang der zweiten Schreibanforderung ein zweites Token an den zweiten Stream-Prozess senden, ohne den ersten Container-Index in den Permanentspeicher zu schreiben.
Das nicht-transitorische maschinenlesbare Medium nach Anspruch 11, das Anweisungen enthält, die bei Ausführung den Prozessor veranlassen,: nach dem Schreiben des ersten Containerindexes in den persistenten Speicher eine erste Schreibbestätigung an den zweiten Stream-Prozess zu senden, wobei die erste Schreibbestätigung mit dem zweiten Token verbunden ist.
Das nicht-transitorische maschinenlesbare Medium nach Anspruch 12, das Anweisungen enthält, die bei der Ausführung den Prozessor veranlassen, nach dem Senden der ersten Schreibbestätigung an den zweiten Stromprozess: von dem ersten Stream-Prozess eine zweite Abschlussanforderung für den ersten Container-Index empfangen; als Reaktion auf den Empfang der zweiten Vervollständigungsanforderung festzustellen, ob der erste Containerindex zuvor in den dauerhaften Speicher geschrieben wurde; und als Reaktion auf die Feststellung, dass der erste Containerindex zuvor in den Permanentspeicher geschrieben wurde, eine zweite Schreibbestätigung an den ersten Stream-Prozess zu senden, wobei die zweite Schreibbestätigung mit dem ersten Token verknüpft ist.
Das nicht-transitorische maschinenlesbare Medium nach Anspruch 13, wobei die erste Beendigungsanforderung das zweite Token enthält, das an den zweiten Stromprozess gesendet wird, und wobei die zweite Beendigungsanforderung das erste Token enthält, das an den ersten Stromprozess gesendet wird.
Das nicht-transitorische maschinenlesbare Medium nach Anspruch 11, das Anweisungen enthält, die bei Ausführung den Prozessor veranlassen,: von dem ersten Stream-Prozess eine dritte Schreibanforderung für einen zweiten Container-Index im Speicher empfangen; als Reaktion auf den Empfang der dritten Schreibanforderung ein drittes Token an den ersten Stromprozess zu senden, wobei das dritte Token mit einem ersten Vertrag zur Aufrechterhaltung des zweiten Containerindex verbunden ist.
Ein Speichersystem, das Folgendes umfasst: einen Prozessor mit einer Vielzahl von Verarbeitungsmaschinen; und einen maschinenlesbaren Speicher, der Befehle speichert, wobei die Befehle vom Prozessor ausgeführt werden können, um: von einem ersten Stream-Prozess eine erste Schreibanforderung für einen ersten Container-Index im Speicher empfangen; als Reaktion auf den Empfang der ersten Schreibanforderung ein erstes Token an den ersten Stream-Prozess senden, ohne den ersten Container-Index in einen dauerhaften Speicher zu schreiben; von einem zweiten Stromprozess eine erste Beendigungsanforderung für den ersten Containerindex empfangen; und als Reaktion auf den Empfang der ersten Abschlussanforderung den ersten Containerindex aus dem Speicher in den Permanentspeicher zu schreiben.
Das Speichersystem nach Anspruch 16, das Anweisungen enthält, die vom Prozessor ausgeführt werden können, um vor dem Empfang der ersten Beendigungsanforderung vom zweiten Stromprozess: vom zweiten Stromprozess eine zweite Schreibanforderung für den ersten Containerindex im Speicher empfangen; als Reaktion auf den Empfang der zweiten Schreibanforderung ein zweites Token an den zweiten Stream-Prozess senden, ohne den ersten Container-Index in den Permanentspeicher zu schreiben.
Das Speichersystem nach Anspruch 17, einschließlich Anweisungen, die vom Prozessor ausgeführt werden können, um: nach dem Schreiben des ersten Containerindexes in den persistenten Speicher eine erste Schreibbestätigung an den zweiten Stream-Prozess zu senden, wobei die erste Schreibbestätigung mit dem zweiten Token verbunden ist.
Das Speichersystem nach Anspruch 18, das Anweisungen enthält, die vom Prozessor ausgeführt werden können, um nach dem Senden der ersten Schreibbestätigung den zweiten Datenstrom zu verarbeiten: von dem ersten Stream-Prozess eine zweite Abschlussanforderung für den ersten Container-Index empfangen; als Reaktion auf den Empfang der zweiten Vervollständigungsanforderung festzustellen, ob der erste Containerindex zuvor in den dauerhaften Speicher geschrieben wurde; und als Reaktion auf die Feststellung, dass der erste Containerindex zuvor in den Permanentspeicher geschrieben wurde, eine zweite Schreibbestätigung an den ersten Stream-Prozess zu senden, wobei die zweite Schreibbestätigung mit dem ersten Token verknüpft ist.
Das Speichersystem nach Anspruch 19, wobei die erste Beendigungsanforderung das zweite Token enthält, das an den zweiten Stream-Prozess gesendet wurde, und wobei die zweite Beendigungsanforderung das erste Token enthält, das an den ersten Stream-Prozess gesendet wurde.