DE102021127177B4

DE102021127177B4 - Container-index mit einer tracking-datenstruktur

Info

Publication number: DE102021127177B4
Application number: DE102021127177.0A
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-20
Publication date: 2024-01-18
Anticipated expiration: 2041-10-21
Also published as: US20220147263A1; CN114442917B; CN114442917A; DE102021127177A1; US11550493B2

Abstract

Ein Verfahren (900), das Folgendes umfasst:Erfassen eines Reset-Ereignisses während eines Deduplizierungsvorgangs;Laden (910) eines Manifests (150) aus einem persistenten Speicher (140) in einen Speicher (115) durch einen Speichercontroller (110), wobei das Manifest (150) eine Reihenfolge von Dateneinheiten in einem Datenstrom (105) angibt;Laden (920) eines ersten Containerindex aus dem persistenten Speicher (140) in den Speicher (115) durch den Speichercontroller (110), wobei der erste Containerindex:eine Tracking-Datenstruktur (300) umfasst, die Identifikatoren von Manifesten enthält;Informationen enthält, die Speicherorte einer Vielzahl von Dateneinheiten angibt; undmit dem in den Speicher (115) geladenen Manifest (150) verknüpft ist;als Reaktion auf das Erfassen des Reset-Ereignisses während des Deduplizierungsvorgangs, Bestimmen (930), durch den Speichercontroller (110), ob die Tracking-Datenstruktur (300) des ersten Containerindex einen Identifikator des Manifests (150) enthält; undals Reaktion auf die Bestimmung, dass die Tracking-Datenstruktur (300) des ersten Containerindex den Identifikator des Manifests nicht enthält, Verwerfen (940) des Manifests (150) durch den Speichercontroller (110).

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.
US 2020 / 0 320 040 A1 beschreibt einen Artikel, der mindestens ein nichtflüchtiges maschinenlesbares Speichermedium umfasst, das Anweisungen umfasst, die von mindestens einer Verarbeitungsressource eines Deduplizierungssystems ausführbar sind, um: Datenblöcke in mindestens einem Container eines Deduplizierungsspeichers zu speichern, in mindestens einem Containerindex Folgendes zu speichern: Chunk-Signaturen und Chunk-Standortdaten für jeden der Chunks, und für jede Chunk-Signatur mindestens ein persistentes Element-Tag, das jeweils der Chunk-Signatur entspricht und ein entsprechendes Sicherungselement des Deduplizierungsspeichers identifiziert, das auf die Chunk-Signatur verweist oder zuvor referenziert hat, als Reaktion auf eine Anforderung zum Löschen eines ersten Backup-Elements der Backup-Elemente jeden Block zu löschen, auf den ausschließlich das erste Backup-Element verweist, ohne einen Block zu löschen, auf den ein zweites Backup-Element der Backup-Elemente verweist, nach einer Anforderung zum Löschen des zweiten Backup-Elements und basierend auf den persistenten Element-Tags im mindestens einen ContainerIndex festzustellen, dass alle Chunks, auf die zuvor vom ersten Backup-Element verwiesen wurde, gelöscht wurden, und als Reaktion auf die Feststellung einen Hinweis auszugeben, dass das erste Sicherungselement gelöscht wurde.
Kurzbeschreibung
Es wird ein Verfahren gemäß Ansprüchen 1 bis 8, ein nicht-transitorisches maschinenlesbares Medium gemäß Ansprüchen 9 bis 15 und ein Speichersystem gemäß Ansprüchen 16 bis 20 offenbart.
Kurzbeschreibung der Zeichnungen
Einige Ausführungsformen werden anhand der folgenden Abbildungen beschrieben.

ist ein schematisches Diagramm eines Beispielspeichersystems gemäß einigen Ausführungsformen.
zeigt ein Beispiel für Datenstrukturen in Übereinstimmung mit einigen Implementierungen.
ist eine Illustration einer beispielhaften Tracking-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 eine Illustration eines Beispielprozesses 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 eine Illustration eines Beispielprozesses in Übereinstimmung mit einigen Implementierungen.
ist ein Diagramm eines Beispiels eines maschinenlesbaren Mediums, das Anweisungen in Übereinstimmung mit einigen Implementierungen speichert.
ist ein schematisches Diagramm eines Beispiel-Computergeräts gemäß 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.
Ausführliche 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 Speichercontroller 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 persistente Speicherung kann mit einem oder mehreren persistenten (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 eingehenden Datenstroms 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 eines eingehenden Datenstroms Datenobjekte im Speicher erzeugen und aktualisieren. Zu diesen Datenobjekten können beispielsweise Datencontainer, Manifeste (die die Reihenfolge der empfangenen Dateneinheiten angeben) und Containerindizes (die Speicherinformationen wie Identifikatoren der Datencontainer, Offsets usw. angeben) gehören. 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 persistenten Speicher schreiben (hier auch als „Persistieren“ jedes Objekts bezeichnet).
In einigen Beispielen kann ein konventionell geordneter Prozess zur Persistierung einer Reihe von Manifesten für jedes Manifest die Persistierung eines oder mehrerer mit dem Manifest verbundener Datencontainer, dann die Persistierung eines oder mehrerer mit dem Manifest verbundener Containerindizes und schließlich die Persistierung des Manifests selbst umfassen. Um die transaktionale Integrität der Datenobjekte zu gewährleisten, muss die Speicherung eines ersten Manifests und der zugehörigen Datenobjekte erfolgreich abgeschlossen sein, bevor mit der Speicherung eines anderen Manifests und der zugehörigen Datenobjekte fortgefahren wird. In einigen Beispielen können jedoch mehrere Manifeste mit denselben Datencontainern und Containerindizes verbunden sein. Wenn mehrere Manifeste persistiert werden, können daher dieselben zugehörigen Datencontainer und Containerindizes mehrfach persistiert werden. Dementsprechend können solche konventionell geordneten Persistenzoperationen doppelte und ineffiziente Schreibvorgänge in den persistenten Speicher beinhalten und somit zu relativ langsamen und/oder ineffizienten Deduplizierungsvorgängen führen.
In Übereinstimmung mit einigen Implementierungen der vorliegenden Offenbarung kann ein Speichersystem Containerindizes im Speicher verwenden, die Tracking-Daten enthalten. Die Tracking-Daten jedes Containerindexes können Identifikatoren von Manifesten enthalten, die mit dem Containerindex verbunden sind. Wenn beispielsweise ein Containerindex im Speicher auf der Grundlage eines bestimmten Manifests aktualisiert wird, kann der Identifikator des bestimmten Manifests der Tracking-Datenstruktur dieses Containerindex hinzugefügt werden. Anschließend kann ein Controller als Reaktion auf eine Persistenzanforderung ein bestimmtes Manifest persistieren, ohne zunächst die zugehörigen Datenobjekte (z. B. einen Containerindex und/oder Datencontainer) zu persistieren. Vielmehr können die zugehörigen Datenobjekte zu einem bestimmten Zeitpunkt nach der Persistierung des bestimmten Manifests persistiert werden. Da mehrere Manifeste mit demselben Satz von Datenobjekten verbunden sein können, kann ein einziger Schreibvorgang für diesen Satz von Datenobjekten ausreichen, um die mit den mehreren Manifesten verbundenen Daten zu erhalten.
Anschließend kann bei einem Neustart nach einem Stromausfall oder einem Systemfehler (hier als „Reset-Ereignis“ bezeichnet) die Tracking-Datenstruktur des Containerindex daraufhin überprüft werden, ob sie den Identifikator des Manifests enthält. Ist dies nicht der Fall, kann festgestellt werden, dass das Manifest und/oder die zugehörigen Datenobjekte nicht ordnungsgemäß gespeichert wurden, so dass das Manifest verworfen werden kann. Auf diese Weise kann ein Verlust der Transaktionsintegrität vermieden werden, der daraus resultiert, dass eine herkömmliche Persistenzoperation nicht verwendet wird (d. h. ein Manifest, das nicht ordnungsgemäß zusammen mit den zugehörigen Datenobjekten persistiert wurde, wird nicht verwendet). Auf diese Weise kann das Speichersystem in der Lage sein, Manifeste zu persistieren, ohne zuerst die zugehörigen Containerindizes und Datencontainer persistieren zu müssen. Dementsprechend können einige Implementierungen die Menge der doppelten Datenschreibvorgänge im Zusammenhang mit Persistenzoperationen reduzieren.
1. Beispiel Speichersystem
zeigt ein Beispiel für ein Speichersystem 100, das einen Speichercontroller 110, einen Speicher 115 und einen persistenten Speicher 140 gemäß einigen Implementierungen umfasst. Wie dargestellt, kann der persistente Speicher 140 eine beliebige Anzahl von Manifesten 150, Containerindizes 160 und Datencontainern 170 enthalten. Der persistente Speicher 140 kann ein oder mehrere nicht transitorische Speichermedien wie Festplattenlaufwerke (HDDs), Solid-State-Laufwerke (SSDs), optische Festplatten usw. oder eine Kombination davon umfassen. Der Speicher 115 kann in Form eines Halbleiterspeichers, z. B. eines Arbeitsspeichers mit wahlfreiem Zugriff (RAM), implementiert sein.
In einigen Implementierungen kann das Speichersystem 100 eine Deduplizierung eines empfangenen Datenstroms 105 durchführen. Zum Beispiel kann der Speichercontroller 110 den empfangenen 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 Einheiten 175 unterteilt sein, wobei jede Einheit 175 mehrere gespeicherte Dateneinheiten enthält.
In einer oder mehreren Implementierungen kann der Speichercontroller 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 der Speichercontroller 110 den für die eingehende Dateneinheit erzeugten Fingerabdruck mit den Fingerabdrücken der gespeicherten Dateneinheiten vergleichen. Ergibt dieser Vergleich eine Übereinstimmung, so kann der Speichercontroller 110 feststellen, dass ein Duplikat der eingehenden Dateneinheit bereits im Speichersystem 100 gespeichert ist.
In einigen Implementierungen kann der Speichercontroller 110 ein Manifest 150 erstellen, um die Reihenfolge aufzuzeichnen, in der die Dateneinheiten im 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. Beispielsweise kann der zugehörige Containerindex 160 Informationen enthalten, die angeben, dass die Dateneinheit an einem bestimmten Offset in einer Einheit 175 gespeichert ist und dass die Einheit 175 an einem bestimmten Offset in einem Datencontainer 170 gespeichert ist.
In einigen Implementierungen kann der Speichercontroller 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. Der Speichercontroller 110 kann dann die im Manifest 150 enthaltenen Zeigerdaten verwenden, um die mit den Dateneinheiten verbundenen Containerindizes 160 zu identifizieren. Ferner kann der Speichercontroller 110 die in den identifizierten Containerindizes 160 enthaltenen Informationen verwenden, um die Speicherorte der Dateneinheiten zu bestimmen (z. B. Datencontainer 170, Entität 175, Offsets usw.), und kann dann die Dateneinheiten aus den bestimmten Speicherorten lesen. In einigen Implementierungen kann jeder Containerindex 160 Tracking-Daten 165 enthalten. Wenn der Containerindex 160 erstellt oder aktualisiert wird, um Informationen über ein bestimmtes Manifest 150 aufzunehmen, können die Tracking-Daten 165 aktualisiert werden, um einen Identifikator dieses Manifests 150 aufzunehmen.
2. Beispiel 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 Index 160, eines Datencontainers 170 bzw. einer Entität 175 (dargestellt in ) entsprechen. In einigen Beispielen können die Datenstrukturen 200 von dem Speichercontroller 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 Dateneinheitsdatensätzen 230 und Entitätsdatensätzen 240 enthalten. Jeder Dateneinheitsdatensatz 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ätsidentifikator, 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 Containerindex 220 eine Tracking-Datenstruktur 225 und eine Versionsnummer 235 enthalten. Die Tracking-Datenstruktur 225 kann im Allgemeinen einer Beispielimplementierung der Tracking-Daten 165 entsprechen, die im Containerindex 160 enthalten sind (siehe ). Wenn der Containerindex 220 erstellt oder aktualisiert wird, um Informationen über ein bestimmtes Manifest zu enthalten, kann die Tracking-Datenstruktur 225 einen Identifikator dieses Manifests speichern.
In einigen Implementierungen kann die Versionsnummer 235 eine Generation oder ein relatives Alter der Metadaten im Containerindex anzeigen. Beispielsweise kann die Versionsnummer 235 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 Containerindex 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 der Entitätsidentifikator des bestimmten Dateneinheitsdatensatzes 230 mit dem Entitätsidentifikator 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 Containers 250 und der Entität 260 verwendet werden, und die Dateneinheit kann dann aus dem identifizierten Container 250 und der Entität 260 gelesen werden.
3. Beispiel Tracking-Datenstruktur
zeigt ein Beispiel für die Tracking-Datenstruktur 300 in Übereinstimmung mit einigen Implementierungen. In einigen Beispielen kann die Tracking-Datenstruktur 300 im Allgemeinen einer Beispielimplementierung der Tracking-Daten 225 entsprechen, die im Containerindex 220 enthalten sind (dargestellt in ). Wie in dargestellt, kann die Tracking-Datenstruktur 300 eine bestimmte Anzahl von Identifikatoren („ID“) enthalten, die jeweils ein bestimmtes Manifest eindeutig identifizieren. In einigen Implementierungen kann nur eine Instanz jedes Identifikators in der Tracking-Datenstruktur 300 gespeichert werden.
Wenn ein Containerindex erstellt oder aktualisiert wird, um Daten aus einem bestimmten Manifest aufzunehmen, kann in einigen Implementierungen ein Identifikator dieses Manifests der im Containerindex enthaltenen Tracking-Datenstruktur 300 hinzugefügt werden. Ferner kann ein Identifikator aus der Tracking-Datenstruktur 300 entfernt werden, wenn der Containerindex nicht mehr mit dem identifizierten Manifest verknüpft ist. Wird beispielsweise ein bestimmtes Manifest aus einem Deduplizierungsspeichersystem gelöscht, kann der Identifikator des Manifests aus der Tracking-Datenstruktur 300 eines mit dem Manifest verknüpften Containerindexes entfernt werden. Ein Beispielprozess zum Entfernen von Identifikatoren aus der Tracking-Datenstruktur 300 wird im Folgenden unter Bezugnahme auf beschrieben.
In einigen Implementierungen können die Tracking-Daten (z. B. die Anzahl der Manifest-Identifikatoren), die in der Tracking-Datenstruktur 300 gespeichert werden können, auf einen maximalen Schwellenwert (z. B. 32.000 Einträge) begrenzt werden. Beispielsweise kann die Anzahl der gespeicherten Identifikatoren begrenzt werden, um zu verhindern, dass die Tracking-Datenstruktur 300 eine gewünschte Größe im Speicher überschreitet. Auf diese Weise wird die Anzahl der Manifeste, die einen bestimmten Containerindex verwenden können, auf den maximalen Wert begrenzt. Zwei Beispielprozesse für die Begrenzung der Tracking-Daten in Containerindizes werden im Folgenden unter Bezugnahme auf die beschrieben.
4. Beispielprozess zur Erzeugung von Tracking-Daten
In ist ein Beispielprozess 400 zur Erzeugung von Tracking-Daten in Übereinstimmung mit einigen Implementierungen dargestellt. In einigen Beispielen kann der Prozess 400 kontinuierlich während der Deduplizierungsverarbeitung eines eingehenden Datenstroms durchgeführt werden. Zum Beispiel kann der Speichercontroller 110 den Prozess 400 während der Deduplizierung jedes eingehenden Datenstroms 105 durchführen (siehe ).
Block 410 kann die Aktualisierung eines Manifests und eines zugehörigen Containerindex im Speicher umfassen. Block 420 kann die Speicherung des Identifikators des Manifests in einer Tracking-Datenstruktur des zugehörigen Containerindex umfassen. Beispielsweise kann der Speichercontroller 110 einen Datenstrom 105 empfangen und ein Manifest 150 erzeugen und/oder aktualisieren, um die Reihenfolge aufzuzeichnen, in der Dateneinheiten im Datenstrom 105 empfangen werden. Ferner kann der Speichercontroller 110 einen zugehörigen Containerindex 160 erzeugen und/oder aktualisieren, der die Speicherorte der empfangenen Dateneinheiten (z. B. Identifikatoren von Datencontainern, Offsets) und andere zugehörige Metadaten angibt. Der Speichercontroller 110 kann dann einen eindeutigen Identifikator des Manifests 150 zu den Tracking-Daten 225 des zugehörigen Containerindex 160 hinzufügen.
Block 430 kann den Empfang einer Anforderung zum Schreiben eines Manifests aus dem Speicher in den persistenten Speicher umfassen. Block 440 kann das Schreiben des Manifests aus dem Speicher in den persistenten Speicher umfassen. Beispielsweise kann der Speichercontroller 110 (siehe ) einen Persistenz-Befehl für ein bestimmtes Manifest 150 empfangen und als Reaktion darauf das bestimmte Manifest 150 aus dem Speicher 115 in den persistenten Speicher 140 schreiben. In einigen Beispielen kann der Persistenzbefehl nur dazu führen, dass das bestimmte Manifest 150 persistiert wird (d. h. ohne gleichzeitige Persistierung zugehöriger Containerindizes 160 oder Datencontainer 170). Ferner kann in einigen Beispielen der Persistenzbefehl erzeugt werden, wenn das bestimmte Manifest 150 im Speicher 115 nicht mehr benötigt wird (z. B. wenn die Verarbeitung der mit dem Manifest 150 verbundenen Eingabedaten abgeschlossen ist). Der Prozess 400 kann nach Block 440 beendet werden.
5. Beispielprozess für die Verwendung von Tracking-Daten
In ist ein Beispielprozess 500 für die Verwendung von Tracking-Daten in Übereinstimmung mit einigen Implementierungen dargestellt. In einigen Beispielen kann der Prozess 500 als Reaktion auf ein Reset-Ereignis durchgeführt werden, das während der Deduplizierung eines eingehenden Datenstroms auftritt. Beispielsweise kann der Speichercontroller 110 den Prozess 500 während des Neustarts nach einem Stromausfall oder einem Systemfehler durchführen (siehe ).
Block 510 kann das Erkennen eines Reset-Ereignisses während einer Deduplizierungsoperation beinhalten. Block 520 kann das Laden eines bestimmten Manifests aus dem persistenten Speicher in den Speicher beinhalten. Beispielsweise kann der Speichercontroller 110 (siehe ) erkennen, dass das Speichersystem 100 während der Deduplizierung eines empfangenen Datenstroms 105 zurückgesetzt oder neu gestartet wurde (z. B. aufgrund eines Stromausfalls oder Systemfehlers). Als Reaktion auf diese Erkennung kann der Speichercontroller 110 versuchen, den Deduplizierungsvorgang wieder aufzunehmen, indem er zugehörige Datenobjekte in den Speicher 115 neu lädt, einschließlich eines bestimmten Manifests 150, das die empfangene Reihenfolge der Dateneinheiten im Datenstrom 105 angibt.
Block 530 kann das Identifizieren eines Containerindexes beinhalten, der mit dem bestimmten Manifest verbunden ist. Block 540 kann das Laden des identifizierten Containerindex in den Speicher aus dem persistenten Speicher umfassen. Beispielsweise kann der Speichercontroller 110 unter Bezugnahme auf die , kann der Speichercontroller 110 ein oder mehrere Felder des bestimmten Manifests 150 lesen, das in den Speicher geladen wurde (z.B. das in gezeigte Feld „Containerindex“). Ferner kann der Speichercontroller 110 einen bestimmten Containerindex 160 identifizieren, der mit dem einen oder den mehreren Feldern des bestimmten Manifests 150 übereinstimmt, und den identifizierten Containerindex 160 in den Speicher 115 laden.
Block 550 kann das Durchsuchen von Tracking-Daten im identifizierten Containerindex nach einem Identifikator des bestimmten Manifests umfassen. Im Entscheidungsblock 560 kann festgestellt werden, ob der Identifikator des bestimmten Manifests in den Tracking-Daten enthalten ist. Ist dies nicht der Fall, so kann der Prozess 500 in Block 570 fortgesetzt werden, der das Verwerfen des bestimmten Manifests beinhalten kann. Andernfalls, wenn in Block 560 festgestellt wird, dass der Bezeichner des bestimmten Manifests in den Tracking-Daten enthalten ist, kann der Prozess 500 in Block 580 fortgesetzt werden, was die Wiederaufnahme des Deduplizierungsvorgangs unter Verwendung des bestimmten Manifests beinhalten kann. Zum Beispiel, siehe , kann der Speichercontroller 110 nach einem Identifikator des bestimmten Manifests 150 in den Tracking-Daten 225 des identifizierten Containerindex 160 suchen. Wenn die Kennung des bestimmten Manifests 150 in den Tracking-Daten 225 vorhanden ist, kann der Speichercontroller 110 das bestimmte Manifest 150 verwenden, um den Deduplizierungsvorgang, der durch das Reset-Ereignis unterbrochen wurde, wieder aufzunehmen. Wenn jedoch der Identifikator des bestimmten Manifests 150 in den Tracking-Daten 225 nicht vorhanden ist, dann kann der Speichercontroller 110 veranlassen, dass das bestimmte Manifest 150 aus dem Speicher 115 entfernt wird. Nach entweder Block 570 oder Block 580 kann der Prozess 500 abgeschlossen werden.
6. Beispielprozess für das Capping von Tracking-Daten in einem Containerindex
zeigt einen beispielhaften Prozess 600 zur Kappung von Tracking-Daten in einem Containerindex gemäß einigen Implementierungen. In einigen Beispielen kann der Prozess 600 durchgeführt werden, um zu verhindern, dass die Tracking-Daten in einem Containerindex (z. B. die in gezeigte Verfolgungsdatenstruktur 300) größer als eine gewünschte Größe im Speicher werden.
Block 610 kann die Aktualisierung der Tracking-Daten eines Containerindexes beinhalten, der mit einem Satz von Dateneinheiten verbunden ist. Block 620 kann die Feststellung beinhalten, ob die Gesamtzahl der Identifikatoren in den Tracking-Daten einen Schwellenwert überschreitet. Block 630 kann als Reaktion auf eine Feststellung, dass die Anzahl der Identifikatoren in den Tracking-Daten den Schwellenwert übersteigt, das Erzeugen eines neuen Containerindexes beinhalten, der mit dem Satz der Dateneinheit(en) verbunden ist. Beispielsweise kann der Speichercontroller 110 unter Bezugnahme auf der Tracking-Datenstruktur 300 eines bestehenden Containerindex Identifikatoren hinzufügen, wobei jeder Identifikator ein anderes Manifest identifiziert, das Dateneinheit(en) enthält, die dem Containerindex zugeordnet sind (z. B. zeigt der Containerindex die Speicherorte der Dateneinheit(en) an). Der Speichercontroller 110 kann feststellen, dass die Anzahl der in der Tracking-Datenstruktur 300 gespeicherten Identifikatoren einen maximalen Schwellenwert überschreitet, und daraufhin einen neuen Containerindex erstellen, der ab diesem Zeitpunkt für diese Dateneinheit(en) verwendet wird, anstatt den bestehenden Containerindex zu verwenden. Anders ausgedrückt: Nach Erreichen des maximalen Schwellenwerts wird ein neues Manifest, das Dateneinheiten enthält, auf die zuvor der bestehende Containerindex verwiesen hätte, stattdessen durch den neuen Containerindex referenziert, und daher wird der Identifikator des neuen Manifests in die Tracking-Datenstruktur 300 des neuen Containerindex aufgenommen. Es ist zu beachten, dass in solchen Implementierungen dieselbe(n) Dateneinheit(en) in mehreren Datencontainern gespeichert sein können und in mehreren Containerindizes referenziert werden können. Nach Block 630 kann der Prozess 600 beendet werden.
7. Beispielprozess für das Capping von Tracking-Daten in einem Containerindex
zeigt ein Beispiel für einen Prozess 700 zur Begrenzung der Tracking-Daten in einem Containerindex in Übereinstimmung mit einigen Implementierungen. In einigen Beispielen kann der Prozess 700 durchgeführt werden, um zu verhindern, dass die Tracking-Daten in einem Containerindex (z. B. die in gezeigte Tracking-Datenstruktur 300) größer als eine gewünschte Größe im Speicher werden.
Block 710 kann die Aktualisierung der Tracking-Daten eines Containerindexes beinhalten, der mit einem Satz von Dateneinheiten verbunden ist. Block 720 kann die Feststellung beinhalten, ob die Gesamtzahl der Identifikatoren in den Tracking-Daten einen Schwellenwert überschreitet. Block 730 kann als Reaktion auf die Feststellung, dass die Anzahl der Identifikatoren in den Tracking-Daten den Schwellenwert überschreitet, die Kennzeichnung des Containerindex als permanent beinhalten. Beispielsweise kann der Speichercontroller 110 unter Bezugnahme auf der Tracking-Datenstruktur 300 eines bestehenden Containerindex Identifikatoren hinzufügen, wobei jeder Identifikator ein anderes Manifest identifiziert, das Dateneinheit(en) enthält, die mit dem Containerindex verbunden sind. Der Speichercontroller 110 kann feststellen, dass die Anzahl der in der Tracking-Datenstruktur 300 gespeicherten Identifikatoren einen maximalen Schwellenwert überschreitet, und kann daraufhin den Containerindex als permanenten Containerindex kennzeichnen. In einigen Beispielen kann jeder Containerindex ein spezielles Feld oder Bit enthalten, um anzuzeigen, ob er als permanent gekennzeichnet ist. Als „permanenter Containerindex“ wird hier ein Containerindex bezeichnet, der nicht wie andere Containerindizes auf der Grundlage der jüngsten Nutzung gelöscht wird, sondern im Vergleich zu anderen Containerindizes über einen relativ langen Zeitraum aufrechterhalten wird. In einigen Implementierungen wird ein Containerindex, der als permanent gekennzeichnet ist, nicht mehr mit neuen Informationen aktualisiert (z. B. im Dateneinheitsdatensatz 230, im Entitätsdatensatz 240 oder in der in gezeigten Tracking-Datenstruktur 225). Beispielsweise werden die Referenzzählfelder des Containerindexes nicht mehr aktualisiert, nachdem er als permanent gekennzeichnet wurde. Wenn der Containerindex nur teilweise gefüllt ist, bleibt er ab dem Zeitpunkt, an dem er als permanent gekennzeichnet wird, teilweise gefüllt. Nach Block 730 kann der Prozess 700 beendet werden.
8. Beispielprozess für die Entfernung eines Manifests
zeigt ein Beispiel für einen Prozess 800 zum Entfernen eines Manifests in Übereinstimmung mit einigen Implementierungen. In einigen Beispielen kann der Prozess 800 durchgeführt werden, wenn ein Manifest aus dem System entfernt wird (z. B. wenn der zugehörige Datenstrom veraltet ist und/oder nicht mehr benötigt wird). Der Prozess 800 kann verwendet werden, um Entfernungen außerhalb der Reihenfolge durchzuführen, und kann doppelte Housekeeping-Operationen vermeiden (z. B. Dekremente von Referenzzählungen).
Block 810 kann das Erkennen einer Anforderung zum Entfernen eines Manifests aus einem Deduplizierungssystem beinhalten. Block 820 kann die Identifizierung eines Containerindexes auf der Grundlage des Manifests beinhalten. Block 830 kann das Laden des Containerindexes aus dem persistenten Speicher in den Speicher beinhalten. Zum Beispiel, bezogen auf die , kann der Speichercontroller 110 einen Befehl oder eine Anzeige zum Entfernen eines Manifests 150 aus dem Speichersystem 100 erkennen (z. B. wenn der durch das Manifest 150 repräsentierte Datenstrom nicht mehr benötigt wird). Als Reaktion auf diese Erkennung kann der Speichercontroller 110 einen Containerindex 160 auf der Grundlage eines oder mehrerer Felder des Manifests 150 identifizieren (z. B. unter Verwendung des in gezeigten Feldes „Containerindex“) und den identifizierten Containerindex 160 aus dem persistenten Speicher 140 in den Speicher 115 laden.
Block 840 kann die Aktualisierung der Referenzzahlen im Containerindex beinhalten. Block 850 kann das Löschen eines Identifikators des Manifests aus den Tracking-Daten des Containerindex umfassen. Block 860 kann das Schreiben des Containerindex in den persistenten Speicher umfassen. Block 870 kann das Löschen des Manifests aus dem persistenten Speicher umfassen. Beispielsweise kann der Speichercontroller 110 (siehe ) ein oder mehrere Felder des Containerindex 220 (z.B. das in gezeigte Feld „Zählung“) aktualisieren, um die Löschung des Manifests 150 zu berücksichtigen. Ferner kann der Speichercontroller 110 den eindeutigen Identifikator des Manifests aus den Tracking-Daten 225 des identifizierten Containerindex 160 entfernen (z. B. durch Entfernen von „ID-2“ aus der in dargestellten Tracking-Datenstruktur 300). Der Speichercontroller 110 kann dann den identifizierten Containerindex 160 aus dem Speicher 115 in den persistenten Speicher 140 schreiben und das Manifest 150 aus dem persistenten Speicher 140 löschen. Nach Block 870 kann der Prozess 800 beendet werden.
9. Beispielprozess für die Verwendung von Tracking-Daten
zeigt ein Beispiel für einen Prozess 900 zur Verwendung von Tracking-Daten in Übereinstimmung mit einigen Implementierungen. In einigen Beispielen kann der Prozess 900 durchgeführt werden, um einen Deduplizierungsprozess nach einem Reset-Ereignis wiederherzustellen oder zu reinitialisieren. Beispielsweise kann der Speichercontroller 110 den Prozess 500 während des Neustarts nach einem Stromausfall oder einem Systemfehler durchführen (siehe ).
Block 910 kann das Laden eines Manifests aus einem persistenten Speicher in den Speicher durch einen Speichercontroller beinhalten. Block 920 kann das Laden eines ersten Containerindexes aus einem persistenten Speicher in den Speicher durch den Speichercontroller umfassen, wobei der erste Containerindex mit dem in den Speicher geladenen Manifest verknüpft ist. Zum Beispiel, unter Bezugnahme auf die , kann der Speichercontroller 110 erkennen, dass das Speichersystem 100 während der Deduplizierung eines empfangenen Datenstroms 105 zurückgesetzt oder neu gestartet wurde (z. B. aufgrund eines Stromausfalls oder Systemfehlers). Als Reaktion auf diese Erkennung kann der Speichercontroller 110 versuchen, den Deduplizierungsvorgang wieder aufzunehmen, indem er ein bestimmtes Manifest 150 in den Speicher 115 lädt (z. B. ein bestimmtes Manifest 150, das die empfangene Reihenfolge der Dateneinheiten im Datenstrom 105 angibt). Ferner kann der Speichercontroller 110 ein oder mehrere Felder des Manifests 150 (z. B. das in gezeigte Feld „Containerindex“) verwenden, um einen Containerindex 160 zu identifizieren, der dem Manifest 150 zugeordnet ist, und kann den identifizierten Containerindex 160 in den Speicher 115 laden.
Block 930 kann beinhalten, dass der Speichercontroller feststellt, ob eine Tracking-Datenstruktur des ersten Containerindex ein Identifikator des Manifests enthält. Block 940 kann als Reaktion auf die Feststellung, dass die Tracking-Datenstruktur des ersten Containerindex den Identifikator des Manifests nicht enthält, das Verwerfen des Manifests durch der Speichercontroller umfassen. Zum Beispiel, unter Bezugnahme auf die , kann der Speichercontroller 110 nach einem Identifikator des Manifests 150 in den Tracking-Daten 225 des identifizierten Containerindex 160 suchen. Wenn der Identifikator des Manifests 150 in den Tracking-Daten 225 vorhanden ist, kann der Speichercontroller 110 das Manifest 150 verwenden, um den Deduplizierungsvorgang, der durch das Reset-Ereignis unterbrochen wurde, wiederherzustellen oder fortzusetzen. Andernfalls, wenn der Identifikator des Manifests 150 nicht in den Tracking-Daten 225 vorhanden ist, kann der Speichercontroller 110 das Manifest 150 aus dem Speicher 115 löschen. Nach Block 940 kann der Prozess 900 abgeschlossen werden.
10. Beispiel maschinenlesbares Medium
zeigt ein maschinenlesbares Medium 1000, auf dem Anweisungen 1010-1040 in Übereinstimmung mit einigen Implementierungen gespeichert sind. Die Anweisungen 1010-1040 können von einem einzelnen Prozessor, mehreren Prozessoren, einer einzelnen Verarbeitungsmaschine, mehreren Verarbeitungsmaschinen usw. ausgeführt werden. Das maschinenlesbare Medium 1000 kann ein nicht-transitorisches Speichermedium sein, wie z. B. ein optisches, Halbleiter- oder magnetisches Speichermedium.
Die Anweisung 1010 kann ausgeführt werden, um einen Manifestteil aus dem persistenten Speicher in den Speicher zu laden. Die Anweisung 1020 kann ausgeführt werden, um einen ersten Containerindex aus dem persistenten Speicher in den Speicher zu laden, wobei der erste Containerindex mit dem in den Speicher geladenen Manifestteil verknüpft ist. Die Anweisung 1030 kann ausgeführt werden, um festzustellen, ob eine Tracking-Datenstruktur des Containerindexes einen Identifikator des Manifests enthält. Die Anweisung 1040 kann ausgeführt werden, um als Reaktion auf die Feststellung, dass die Tracking-Datenstruktur des Containerindex nicht den Bezeichner des Manifests enthält, das Manifest zu verwerfen.
11. Beispiel Rechenvorrichtung
zeigt ein schematisches Diagramm einer beispielhaften Rechenvorrichtung 1100. In einigen Beispielen kann die Rechenvorrichtung 1100 im Allgemeinen einem Teil oder der Gesamtheit des Speichersystems 100 (dargestellt in ) entsprechen. Wie dargestellt, kann die Rechenvorrichtung 1100 einen Hardware-Prozessor 1102 und einen maschinenlesbaren Speicher 1105 mit den Befehlen 1110-1140 enthalten. Der maschinenlesbare Speicher 1105 kann ein nicht-übertragbares Medium sein. Die Befehle 1110-1140 können von dem Hardware-Prozessor 1102 oder von einer im Hardware-Prozessor 1102 enthaltenen Verarbeitungsmaschine ausgeführt werden.
Die Anweisung 1110 kann ausgeführt werden, um einen Manifestteil aus dem persistenten Speicher in den Speicher zu laden. Die Anweisung 1120 kann ausgeführt werden, um einen ersten Containerindex aus dem persistenten Speicher in den Speicher zu laden, wobei der erste Containerindex mit dem in den Speicher geladenen Manifestteil verknüpft ist. Die Anweisung 1130 kann ausgeführt werden, um festzustellen, ob eine Tracking-Datenstruktur des Containerindex einen Identifikator des Manifests enthält. Die Anweisung 1140 kann ausgeführt werden, um als Reaktion auf die Feststellung, dass die Tracking-Datenstruktur des Containerindex nicht den Bezeichner des Manifests enthält, das Manifest zu verwerfen.
In Übereinstimmung mit den hier beschriebenen Implementierungen kann ein Speichersystem Containerindizes verwenden, die Tracking-Daten enthalten. Die Tracking-Daten jedes Containerindexes können Identifikatoren von Manifesten enthalten, die mit dem Containerindex verbunden sind. Als Reaktion auf eine Persistenzanforderung kann ein Controller ein bestimmtes Manifest persistieren, ohne auch einen zugehörigen Containerindex und einen zugehörigen Datencontainer zu persistieren. Wenn das bestimmte Manifest erfolgreich in den persistenten Speicher geschrieben wird, kann der Identifikator des bestimmten Manifests der Tracking-Datenstruktur des zugehörigen Containerindex hinzugefügt werden. Anschließend kann bei einem Neustart des Systems nach einem Stromausfall oder einer Störung die Tracking-Datenstruktur des Containerindex daraufhin überprüft werden, ob sie den Identifikator des Manifests enthält. Ist dies nicht der Fall, kann davon ausgegangen werden, dass das Manifest nicht ordnungsgemäß gespeichert wurde, so dass es verworfen werden kann. Auf diese Weise kann das Speichersystem Manifeste aufbewahren, ohne auch die zugehörigen Containerindizes und Datencontainer aufbewahren zu müssen. Dementsprechend können einige Implementierungen die Menge der doppelten Datenschreibvorgänge im Zusammenhang mit Persistenzoperationen reduzieren.
Beachten Sie, dass die verschiedene Beispiele zeigen, sind die Implementierungen in dieser Hinsicht nicht beschränkt. Beispielsweise kann das Speichersystem 100, wie in gezeigt, 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 Speichercontrollers 110 in einer anderen Maschine oder Software des Speichersystems 100 enthalten sein kann. Andere Kombinationen und/oder Variationen sind ebenfalls möglich.
Siehe nun die können die dargestellten Prozesse (d.h. die Prozesse 400, 500, 600, 700, 800 und 900) unter Verwendung der Speichercontroller 110 (dargestellt in ) durchgeführt werden. Die dargestellten Prozesse können 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 einer optischen, Halbleiter- oder magnetischen Speichereinrichtung. Die maschinenlesbaren Anweisungen können von einem einzigen Prozessor, mehreren Prozessoren, einer einzigen Verarbeitungsmaschine, mehreren Verarbeitungsmaschinen usw. ausgeführt werden. Zur Veranschaulichung wurden einige Details der dargestellten Verfahren bereits oben unter Bezugnahme auf die beschrieben, die Beispiele für einige Implementierungen zeigen. Es sind jedoch auch andere Implementierungen 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 sind 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 (900), das Folgendes umfasst: Erfassen eines Reset-Ereignisses während eines Deduplizierungsvorgangs; Laden (910) eines Manifests (150) aus einem persistenten Speicher (140) in einen Speicher (115) durch einen Speichercontroller (110), wobei das Manifest (150) eine Reihenfolge von Dateneinheiten in einem Datenstrom (105) angibt; Laden (920) eines ersten Containerindex aus dem persistenten Speicher (140) in den Speicher (115) durch den Speichercontroller (110), wobei der erste Containerindex: eine Tracking-Datenstruktur (300) umfasst, die Identifikatoren von Manifesten enthält; Informationen enthält, die Speicherorte einer Vielzahl von Dateneinheiten angibt; und mit dem in den Speicher (115) geladenen Manifest (150) verknüpft ist; als Reaktion auf das Erfassen des Reset-Ereignisses während des Deduplizierungsvorgangs, Bestimmen (930), durch den Speichercontroller (110), ob die Tracking-Datenstruktur (300) des ersten Containerindex einen Identifikator des Manifests (150) enthält; und als Reaktion auf die Bestimmung, dass die Tracking-Datenstruktur (300) des ersten Containerindex den Identifikator des Manifests nicht enthält, Verwerfen (940) des Manifests (150) durch den Speichercontroller (110).
Das Verfahren (900) nach Anspruch 1, umfassend: als Reaktion auf die Bestimmung, dass die Tracking-Datenstruktur (300) des ersten Containerindex den Identifikator des Manifests (150) enthält, Wiederaufnehmen des Deduplizierungsvorgangs unter Verwendung des Manifests (150).
Das Verfahren (900) nach Anspruch 2, umfassend: Laden des Manifests (150) aus dem persistenten Speicher (140) in den Speicher (115).
Das Verfahren (900) nach Anspruch 2, das vor dem Laden des Manifests (150) aus dem persistenten Speicher (140) in den Speicher (115) Folgendes umfasst: Aktualisieren des Manifests (150) im Speicher (115) während des Deduplizierungsvorgangs; Aktualisieren des ersten Containerindex basierend auf dem aktualisierten Manifest; und nach dem Aktualisieren des ersten Containerindex basierend auf dem aktualisierten Manifest, Speichern eines Identifikators des Manifests (150) in der Tracking-Datenstruktur (300) des ersten Containerindex.
Das Verfahren (900) nach Anspruch 1, das vor dem Laden des ersten Containerindexes aus dem persistenten Speicher (140) in den Speicher (115) Folgendes umfasst: Identifizieren des ersten Containerindex basierend auf mindestens einem Feld des in den Speicher (115) geladenen Manifests (150); und als Reaktion auf eine Identifizierung des ersten Containerindex basierend auf des-dem mindestens einen Feld, Laden des ersten Containerindex aus dem persistenten Speicher (140) in den Speicher (115).
Das Verfahren (900) nach Anspruch 1, umfassend: Schreiben einer Vielzahl von Manifesten (150) aus dem Speicher (115) in den persistenten Speicher (140); und Speichern einer Vielzahl von Identifikatoren in der Tracking-Datenstruktur (300) des ersten Containerindex, wobei jede der Vielzahl von Identifikatoren ein anderes Manifest der Vielzahl von Manifesten (150) identifiziert.
Das Verfahren (900) nach Anspruch 1, umfassend: Bestimmen, ob eine Gesamtzahl von Identifikatoren in der Tracking-Datenstruktur (300) des ersten Containerindex einen Schwellenwert überschreitet; und als Reaktion auf die Bestimmung, dass die Gesamtzahl von Identifikatoren in der Tracking-Datenstruktur (300) des ersten Containerindex den Schwellenwert überschreitet, Erzeugen eines zweiten Containerindex.
Das Verfahren (900) nach Anspruch 1, umfassend: Bestimmen, ob eine Gesamtzahl von Identifikatoren in der Tracking-Datenstruktur (300) des ersten Containerindex einen Schwellenwert überschreitet; und als Reaktion auf die Bestimmung, dass die Gesamtzahl von Identifikatoren in der Tracking-Datenstruktur (300) des ersten Containerindex den Schwellenwert überschreitet, Kennzeichnen des ersten Containerindex als permanenter Containerindex.
Ein nicht-transitorisches maschinenlesbares Medium (1000; 1105), das durch einen Prozessor ausführbare Anweisungen speichert zum: Erfassen eines Reset-Ereignisses während eines Deduplizierungsvorgangs; Laden (1010; 1110) eines Manifests (150) aus dem persistenten Speicher (140) in einen Speicher (115), wobei das Manifest (150) eine Reihenfolge von Dateneinheiten in einem Datenstrom (105) angibt; Laden (1020; 1120) eines ersten Containerindex aus dem persistenten Speicher (140) in den Speicher (115), wobei der erste Containerindex: eine Tracking-Datenstruktur (300) enthält, die Identifikatoren von Manifesten enthält; Informationen enthält, die Speicherorte einer Vielzahl von Dateneinheiten angibt; und mit dem in den Speicher (115) geladenen Manifest (150) verknüpft ist; als Reaktion auf das Erfassen des Reset-Ereignisses während des Deduplizierungsvorgangs, Bestimmen (1030; 1130), ob die Tracking-Datenstruktur (300) des ersten Containerindex einen Identifikator des Manifests (150) enthält; und als Reaktion auf die Bestimmung, dass die Tracking-Datenstruktur (300) des ersten Containerindex den Identifikator des Manifests nicht enthält, Verwerfen (1040; 1140) des Manifests (150).
Das nicht-transitorische maschinenlesbare Medium (1000; 1105) nach Anspruch 9, das durch einen Prozessor ausführbare Anweisungen enthält, zum: als Reaktion auf die Bestimmung, dass die Tracking-Datenstruktur (300) des ersten Containerindex den Identifikator des Manifests (150) enthält, Wiederaufnehmen des Deduplizierungsvorgangs unter Verwendung des Manifests (150).
Das nicht-transitorische maschinenlesbare Medium (1000; 1105) nach Anspruch 10, das durch einen Prozessor ausführbare Anweisungen enthält, zum: Laden des Manifests (150) aus dem persistenten Speicher (140) in den Speicher (115).
Das nicht-transitorische maschinenlesbare Medium (1000; 1105) nach Anspruch 10, das durch einen Prozessor ausführbare Anweisungen enthält, zum, vor dem Laden des Manifests (150) aus dem persistenten Speicher (140) in den Speicher (115): Aktualisieren des Manifests (150) im Speicher (115) während des Deduplizierungsvorgangs; Aktualisieren des ersten Containerindex basierend auf dem aktualisierten Manifest; und nach dem Aktualisieren des ersten Containerindex basierend auf dem aktualisierten Manifest, Speichern eines Identifikators des Manifests (150) in der Tracking-Datenstruktur (300) des ersten Containerindex.
Das nicht-transitorische maschinenlesbare Medium (1000; 1105) nach Anspruch 9, das durch einen Prozessor ausführbare Anweisungen enthält, zum, vor dem Laden des ersten Containerindex aus dem persistenten Speicher (140) in den Speicher (115): Identifizieren des ersten Containerindex basierend auf mindestens einem Feld des in den Speicher (115) geladenen Manifests (150); und als Reaktion auf eine Identifizierung des ersten Containerindex basierend auf des-dem mindestens einen Feld Laden des ersten Containerindex aus dem persistenten Speicher (140) in den Speicher (115).
Das nicht-transitorische maschinenlesbare Medium (1000; 1105) nach Anspruch 9, das durch einen Prozessor ausführbare Anweisungen enthält, zum: als Reaktion auf eine Bestimmung, dass eine Gesamtzahl von Identifikatoren in der Tracking-Datenstruktur (300) des ersten Containerindex einen Schwellenwert überschreitet, Erzeugen eines zweiten Containerindex.
Das nicht-transitorische maschinenlesbare Medium (1000; 1105) nach Anspruch 9, das durch einen Prozessor ausführbare Anweisungen enthält, zum: als Reaktion auf eine Bestimmung, dass eine Gesamtzahl von Identifikatoren in der Tracking-Datenstruktur (300) des ersten Containerindex einen Schwellenwert überschreitet, Kennzeichnen des ersten Containerindex als permanenten Containerindex.
Ein Speichersystem (100, 1100), das Folgendes umfasst: einen Prozessor (1102); und einen maschinenlesbaren Speicher (1105), der Anweisungen speichert, wobei die Anweisungen vom Prozessor (1102) ausgeführt werden können, zum: Erfassen eines Reset-Ereignisses während eines Deduplizierungsvorgangs; Laden (1010; 1110) eines Manifests (150) aus einem persistenten Speicher (140) in einen Speicher (115), wobei das Manifest (150) eine Reihenfolge von Dateneinheiten in einem Datenstrom (105) angibt; Laden (1020; 1120) eines ersten Containerindex aus dem persistenten Speicher (140) in den Speicher (115), wobei der erste Containerindex: eine Tracking-Datenstruktur (300) enthält, die Identifikatoren von Manifesten enthält; Informationen enthält, die Speicherorte einer Vielzahl von Dateneinheiten angibt; und mit dem in den Speicher (115) geladenen Manifest (150) verknüpft ist; als Reaktion auf das Erfassen des Reset-Ereignisses während des Deduplizierungsvorgangs, Bestimmen (1030; 1130), ob die Tracking-Datenstruktur (300) des ersten Containerindex einen Identifikator des Manifests (150) enthält; und als Reaktion auf die Bestimmung, dass die Tracking-Datenstruktur (300) des ersten Containerindex den Identifikator des Manifests (150) nicht enthält, Verwerfen (1040; 1140) des Manifests (150).
Das Speichersystem (100, 1100) nach Anspruch 16, das Anweisungen enthält, die vom Prozessor (1102) ausgeführt werden können, zum: als Reaktion auf die Bestimmung, dass die Tracking-Datenstruktur (300) des ersten Containerindex den Identifikator des Manifests (150) enthält, Wiederaufnehmen des Deduplizierungsvorgangs unter Verwendung des Manifests (150).
Das Speichersystem (100, 1100) nach Anspruch 17, das Anweisungen enthält, die vom Prozessor (1102) ausgeführt werden können, zum: Laden des Manifests (150) aus dem persistenten Speicher (140) in den Speicher (115).
Das Speichersystem (100, 1100) nach Anspruch 17, das Anweisungen enthält, die vom Prozessor (1102) ausgeführt werden können, zum, vor dem Laden des Manifests (150) aus dem persistenten Speicher (140) in den Speicher (115): Aktualisieren des Manifests (150) im Speicher (115) während des Deduplizierungsvorgangs; Aktualisieren des ersten Containerindex basierend auf dem aktualisierten Manifest (150); und nach dem Aktualisieren des ersten Containerindex basierend auf dem aktualisierten Manifest, Speichern eines Identifikators des Manifests (150) in der Tracking-Datenstruktur (300) des ersten Containerindex.
Das Speichersystem (100, 1100) nach Anspruch 16, das Anweisungen enthält, die vom Prozessor (1102) ausgeführt werden können, zum: als Reaktion auf eine Bestimmung, dass eine Gesamtzahl von Identifikatoren in der Tracking-Datenstruktur (300) des ersten Containerindex einen Schwellenwert überschreitet, Kennzeichnen des ersten Containerindex als permanenten Containerindex.