DE102020104701A1 - Cache data location system - Google Patents

Cache data location system Download PDF

Info

Publication number
DE102020104701A1
DE102020104701A1 DE102020104701.0A DE102020104701A DE102020104701A1 DE 102020104701 A1 DE102020104701 A1 DE 102020104701A1 DE 102020104701 A DE102020104701 A DE 102020104701A DE 102020104701 A1 DE102020104701 A1 DE 102020104701A1
Authority
DE
Germany
Prior art keywords
address
cache
physical location
target data
candidate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE102020104701.0A
Other languages
English (en)
Inventor
Matti A. Vanninen
Sudhanshu Goswami
Christopher J. Corsi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102020104701A1 publication Critical patent/DE102020104701A1/de
Granted legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1009—Address translation using page tables, e.g. page table structures
    • G06F12/1018—Address translation using page tables, e.g. page table structures involving hashing techniques, e.g. inverted page tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0871—Allocation or management of cache space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0864—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches using pseudo-associative means, e.g. set-associative or hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0893—Caches characterised by their organisation or structure
    • G06F12/0897—Caches characterised by their organisation or structure with two or more cache hierarchy levels
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G06F12/123—Replacement control using replacement algorithms with age lists, e.g. queue, most recently used [MRU] list or least recently used [LRU] list
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G06F2212/1021—Hit rate improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G06F2212/1024—Latency reduction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/22—Employing cache memory using specific memory technology
    • G06F2212/225—Hybrid cache memory, e.g. having both volatile and non-volatile portions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory
    • G06F2212/608—Details relating to cache mapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/657—Virtual address space management

Abstract

Ein System kann eine persistente Speichervorrichtung, eine Cache-Vorrichtung mit geringer Latenz und einen flüchtigen Speicher enthalten; und ein Prozessor. Der Prozessor soll eine Datenstruktur im flüchtigen Speicher speichern, die verwendet werden kann, um eine logische Blockadresse für Zieldaten direkt an einen physischen Speicherort des Kandidaten auf dem Cache-Gerät zu übersetzen, und einen mehrstufigen Übersetzungsindex im flüchtigen Speicher zum Übersetzen der logischen Blockadresse speichern für die Zieldaten an einen erwarteten physischen Ort der Zieldaten auf dem Cache-Gerät und versuchen Sie, auf die Zieldaten an dem Kandidaten-physischen Ort zuzugreifen, der aus der direkten Cache-Adressübersetzungsdatenstruktur abgerufen wurde. Wenn sich die Zieldaten nicht an der physischen Adresse des Kandidaten befinden, greifen Sie auf die Zieldaten an dem erwarteten physischen Ort zu, der aus dem mehrstufigen Übersetzungsindex abgerufen wurde.

Description

  • HINTERGRUND
  • Viele Computerspeichersysteme können einen Cache enthalten, der Kopien von Daten enthält, die auf langsamer persistenten Medien gespeichert sind. Der Cache bietet einen schnelleren Zugriff auf Daten, die häufiger abgerufen werden. Das Auffinden des physischen Speicherorts oder der physischen Adresse der Daten im Cache kann interne Metadatensuchen umfassen.
  • Figurenliste
    • 1 ist ein Blockdiagramm, das schematisch Teile eines beispielhaften Cache-Datenortungssystems darstellt.
    • 2 ist ein Blockdiagramm, das schematisch Teile eines beispielhaften nicht vorübergehenden computerlesbaren Mediums darstellt, das beispielhafte Anweisungen zum Auffinden von Cache-Daten speichert.
    • 3 ist ein Flussdiagramm einer beispielhaften Cache-Datenortungsmethode.
    • 4 ist ein Blockdiagramm, das schematisch Teile eines beispielhaften Cache-Datenortungssystems darstellt.
    • 5 ist ein Flussdiagramm einer beispielhaften Cache-Datenortungsmethode.
    • 6 ist ein Flussdiagramm einer beispielhaften Cache-Datenortungsmethode.
    • 7 ist ein Diagramm, das Teile einer beispielhaften direkten Cache-Adressübersetzungsdatenstruktur in Form einer beispielhaften Hash-Tabelle darstellt.
  • In allen Zeichnungen bezeichnen identische Referenznummern ähnliche, aber nicht unbedingt identische Elemente. Die Figuren sind nicht unbedingt maßstabsgetreu, und die Größe einiger Teile kann übertrieben sein, um das gezeigte Beispiel deutlicher zu veranschaulichen. Darüber hinaus enthalten die Zeichnungen Beispiele und / oder Implementierungen, die mit der Beschreibung übereinstimmen; Die Beschreibung ist jedoch nicht auf die in den Zeichnungen angegebenen Beispiele und / oder Implementierungen beschränkt.
  • DETAILLIERTE BESCHREIBUNG DER BEISPIELE
  • Hierin werden beispielhafte Systeme, Verfahren und computerlesbare Anweisungen offenbart, die time den Zeitaufwand für den Zugriff auf in einem Cache gespeicherte Daten reduzieren. Die offenbarten Systeme, Verfahren und Anweisungen reduzieren den Zeitaufwand für den Zugriff auf im Cache gespeicherte Daten, indem sie die Zeit zum Identifizieren des physischen Speicherorts von Daten im Cache reduzieren, der hier als „physischer Speicherort des Caches“ bezeichnet werden kann. Mit dem Aufkommen eines schnelleren Cache-Speichers wird die Zeit zum Auffinden von Daten im Cache häufig zum Engpass. Die offenbarten Speichersysteme, -verfahren und -anweisungen beheben diesen Engpass, indem sie eine weniger aktuelle, aber direkte und schnellere Adressübersetzungsdatenstruktur in Kombination mit einem aktuelleren, aber langsameren mehrstufigen Adressübersetzungsindex (der hier als „mehrstufige Übersetzung“ bezeichnet werden kann) verwenden index “) unter Umständen, in denen die direkte Adressumsetzung aufgrund von Datenverschiebung oder Datenentfernung nicht mehr aktuell ist.
  • In einigen Implementierungen werden Kopien von Daten, die auf langsamer persistenten Medien wie einem Festplattenlaufwerk gespeichert sind, auch auf einem Cache-Gerät mit geringer Latenz, wie einem SCM-Gerät (Storage Class Memory), verwaltet. In einer solchen Implementierung kann auf die auf dem Cache-Gerät mit niedriger Latenz gespeicherten Daten zugegriffen werden, indem einer oder beide von zwei verschiedenen Adressübersetzungsmechanismen verwendet werden, die in einem flüchtigen Speicher (z. B. DRAM oder dergleichen) gespeichert sind. Der flüchtige Speicher speichert eine direkte Cache-Adressdatenstruktur, die unter Verwendung einer Hash-Tabelle implementiert werden kann. Der flüchtige Speicher speichert auch einen mehrstufigen Übersetzungsindex, der logische Blockadressen in entsprechende physische Cache-Adressen übersetzt. Für jede von mehreren logischen Blockadressen (die als „Hostadressen“ oder „Benutzereingabeadressen“ bezeichnet werden können) kann die schnellere direkte Cache-Adressübersetzungsdatenstruktur eine logische Blockadresse direkt in eine physikalische Kandidatenadresse von übersetzen ein physischer Speicherort eines Kandidaten im Cache, der eine aktuelle oder frühere Version der angeforderten oder gezielten Daten enthalten kann. Unter Umständen, in denen die Zieldaten nicht mehr an dem durch die direkte Cache-Adressübersetzungsdatenstruktur identifizierten physischen Standort des Kandidaten vorhanden sind, z. B. wenn die Zieldaten innerhalb des Cache verschoben wurden, wird der mehrstufige Übersetzungsindex verwendet, um eine tatsächliche physische Adresse von zu identifizieren Ein erwarteter physischer Speicherort im Cache, der die Zieldaten enthält.
  • Wie oben offenbart, wird zuerst die direkte Cache-Adressübersetzungsdatenstruktur verwendet, um zu versuchen, die durch die logische Blockadresse identifizierten Zieldaten zu lokalisieren. In vielen Fällen befinden sich die Zieldaten jedoch möglicherweise nicht mehr an dem physischen Standort des Kandidaten, der durch die physische Adresse des Kandidaten identifiziert wird, die aus der direkten Cache-Adressübersetzungsdatenstruktur basierend auf der logischen Blockadresse erhalten wird. Dies kann darauf zurückzuführen sein, dass die Zieldaten an einen anderen Speicherort im Cache verschoben wurden. Beispielsweise können ältere Daten, die an einem ersten physischen Ort des Caches vorhanden sind, durch neuere Daten überschrieben werden, die an einen zweiten physischen Ort des Caches geschrieben werden, was dazu führt, dass die älteren Daten nicht mehr aktuell sind. Während eines manchmal als „Garbage Collection“ bezeichneten Prozesses werden alle aktuellen Daten gesammelt und mit anderen aktuellen Daten an anderen physischen Stellen im Cache konzentriert. Beispielsweise kann ein solcher Speicherbereinigungsprozess die neueren Daten am zweiten physischen Speicherort an einen dritten physischen Speicherort des Caches kopieren und sowohl die alten Daten am ersten physischen Speicherort (der keine aktuellen Daten mehr sind) als auch den neueren löschen Daten am zweiten physischen Standort (der ursprünglich verwendet wurde, um die älteren Daten am ersten physischen Standort zu überschreiben). Ein solcher Speicherbereinigungsprozess führt zu einer Änderung des physischen Speicherorts der neueren Daten, bei denen es sich in diesem Beispiel möglicherweise um die Zieldaten handelt. Wenn diese Änderung auftritt, wird der mehrstufige Übersetzungsindex aktualisiert, um den neuen physischen Speicherort der neueren Daten einzuschließen (z. B. Angabe der neueren Daten, die im obigen Beispiel am dritten physischen Speicherort gespeichert sind). In solchen Beispielen kann der mehrstufige Übersetzungsindex für alle derartigen aktuellen Daten aktualisiert werden, die verschoben wurden. Die direkte Cache-Adressübersetzungsdatenstruktur (hier manchmal als direkte logische Blockadresse zur physischen Adressübersetzungsdatenstruktur bezeichnet) kann jedoch zum Zeitpunkt jedes Speicherbereinigungsprozesses nicht aktualisiert werden. Dies kann dazu führen, dass eine physikalische Adresse, die aus der direkten Cache-Adressübersetzungsdatenstruktur abgerufen oder ausgegeben wird (auf die Bezug genommen werden kann, hat hier eine „physikalische Kandidatenadresse“), insofern ungültig ist, als sie keinem physischen Ort im Cache entspricht, der tatsächlich vorhanden ist enthält die Zieldaten. In den hier beschriebenen Beispielen kann der durch eine physikalische Kandidatenadresse angegebene physikalische Ort als „physikalischer Kandidatenort“ bezeichnet werden.
  • Sobald die physische Adresse des Kandidaten für einen physischen Standort des Kandidaten (der die Zieldaten enthalten kann) aus der direkten Cache-Adressübersetzungsdatenstruktur erhalten wurde, überprüfen die offenbarten Systeme, Verfahren und computerlesbaren Anweisungen, ob sich die Zieldaten tatsächlich beim Kandidaten befinden physischer Standort . In einer Implementierung kann jeder physische Speicherort im Cache eine erste Kennung speichern, die direkt mit den zugewiesenen Daten verknüpft ist und sich mit diesen bewegt (z. B. wenn die Daten wie beim Speicherbereinigungsprozess an einen anderen Speicherort kopiert werden). Der Eintrag in der direkten Cache-Adressübersetzungsdatenstruktur, die die logische Blockadresse mit der physischen Kandidatenadresse verknüpft, enthält eine zweite Kennung, die den Daten zugeordnet ist, von denen erwartet wird, dass sie sich am physischen Standort des Kandidaten befinden. Wenn die direkte Cache-Adressübersetzungsdatenstruktur zum ersten Mal mit der zweiten Kennung gefüllt wird, ist die zweite Kennung dieselbe wie die erste Kennung, die mit den Daten am physischen Standort des Kandidaten gespeichert ist. Sobald die Daten jedoch an einen neuen Speicherort verschoben wurden, beispielsweise aufgrund des oben beschriebenen Speicherbereinigungsprozesses, kann der physische Speicherort des Kandidaten frei von Daten sein oder andere Daten mit einer Kennung speichern, die sich von der zugeordneten Kennung unterscheidet mit der logischen Blockadresse und zuvor in der direkten Cache-Adressübersetzungsdatenstruktur gespeichert.
  • Die offenbarten Systeme, Verfahren und computerlesbaren Anweisungen überprüfen durch Vergleichen der beiden Kennungen, ob sich die Zieldaten tatsächlich am physischen Standort des Kandidaten befinden. Wenn die beiden Kennungen übereinstimmen, sind die Daten am physischen Standort des Kandidaten die Zieldaten, die durch die logische Blockadresse identifiziert werden. Wenn die beiden Kennungen nicht übereinstimmen, sind die Daten am physischen Standort des Kandidaten nicht die Zieldaten, die durch die logische Blockadresse identifiziert werden. Infolgedessen verschieben sich die Systeme, Verfahren und computerlesbaren Anweisungen dann auf die Verwendung des mehrstufigen Übersetzungsindex, um die Zieldaten über eine erste Zuordnung der logischen Blockadresse für die Zieldaten zu einer logischen Cache-Adresse und eine zweite Zuordnung von zu lokalisieren Diese logische Cache-Adresse entspricht der erwarteten (z. B. aktuellen) physischen Adresse der Zieldaten im Cache. Obwohl die Verwendung des mehrstufigen Übersetzungsindex im Vergleich zur direkten Cache-Adressübersetzungsdatenstruktur aufgrund der mehreren Ebenen oder mehreren Übersetzungen die Latenzen erhöht hat, wird der mehrstufige Übersetzungsindex häufiger mit den aktuellen Speicherorten für Daten als Teil aktualisiert des Garbage Collection-Prozesses kann einen aktuelleren und genaueren Ort für die Zieldaten bereitstellen.
  • Sobald die aktuellere Adresse für den „erwarteten“ physischen Speicherort im Cache, der die Zieldaten enthält, im mehrstufigen Übersetzungsindex gefunden oder aus diesem abgerufen wurde, verwenden die Systeme, Methoden und computerlesbaren Anweisungen den erwarteten physischen Speicherort damit die Zieldaten die Datenstruktur der direkten Cache-Adressübersetzung aktualisieren oder korrigieren. Insbesondere wird der alte Eintrag in der direkten Cache-Adressübersetzungsdatenstruktur, der die falsche oder ungültige Kandidatenadresse für die Zieldaten enthält, aus der Datenstruktur entfernt und ein neuer Eintrag ordnet die logische Blockadresse der physischen Adresse für den erwarteten physischen Ort von zu Die aus dem mehrstufigen Übersetzungsindex abgerufenen Zieldaten werden hinzugefügt. Mit anderen Worten, die physische Adresse für den erwarteten physischen Standort der Zieldaten, die vom mehrstufigen Übersetzungsindex ausgegeben wird, wird in der direkten Datenstruktur für die Bargeldadressübersetzung zwischengespeichert. Der „erwartete“ physische Standort kann der Ort sein, an dem sich die Zieldaten aufgrund der häufigeren Aktualisierung des mehrstufigen Übersetzungsindex mit größerer Wahrscheinlichkeit befinden als jeder physische Standort, der durch die direkte Datenstruktur für die Bargeldadressübersetzung bereitgestellt wird. Obwohl möglicherweise eine größere Zuverlässigkeit hinsichtlich des tatsächlichen physischen Standorts für die Zieldaten geboten wird, kann die Ausgabe der physischen Adresse für den erwarteten physischen Standort manchmal aufgrund einer Vielzahl anderer möglicher Ursachen fehlerhaft sein. Infolgedessen wird der Begriff „erwartet“ in der vorliegenden Offenbarung verwendet, wenn die physikalische Adresse für die vom mehrstufigen Übersetzungsindex ausgegebenen Zieldaten beschrieben wird.
  • Bei der Initiierung eines Systems kann die direkte Cache-Adressübersetzungsdatenstruktur Einträge für eine gegebene logische Blockadresse enthalten, die leer sind, oder sie kann jeden Eintrag weglassen, der der logischen Blockadresse entspricht. In Reaktion auf das Identifizieren eines leeren Eintrags oder das Fehlen eines zugeordneten Eintrags für eine logische Blockadresse kann der mehrstufige Übersetzungsindex automatisch herangezogen werden, um die tatsächliche physikalische Adresse des erwarteten physikalischen Ortes zu identifizieren, der die Daten enthält, auf die die logische Blockadresse abzielt. Sobald die tatsächliche physikalische Adresse für den erwarteten physischen Ort der Daten, auf die die logische Blockadresse abzielt, unter Verwendung des mehrstufigen Übersetzungsindex identifiziert worden ist, kann ein leerer Eintrag für die logische Blockadresse in der Datenstruktur mit der tatsächlichen physikalischen Adresse für gefüllt werden Der erwartete physische Standort oder die Datenstruktur können mit einem neuen Eintrag für die logische Blockadresse gefüllt werden, der die tatsächliche physische Adresse für den erwarteten physischen Standort enthält.
  • Ein Beispiel für einen solchen mehrstufigen Übersetzungsindex ist ein Index, der eine erste Ebene enthält, die einen Blockindex umfasst, der einen Baum umfasst, der für jede von mehreren logischen Blockadressen eine logische Blockadresse (z. B. eine Volumen-ID und einen Offset) abbildet und die als „logische Blockadresse“ oder „Hostadresse“ bezeichnet werden können) an eine jeweilige logische Cache-Adresse (z. B. einen Benutzerblock (BU), und die als Datenkennung bezeichnet werden kann). Der Index umfasst ferner eine zweite Ebene, die einen Cache-Index umfasst, der einen Baum umfasst, der für jede von mehreren logischen Cache-Adressen eine logische Cache-Adresse (z. B. den Benutzerblock) einer jeweiligen tatsächlichen physischen Adresse (z. B. Segment-ID und Offset) zuordnet) für einen physischen Cache-Speicherort, an dem die Daten, die der logischen Blockadresse entsprechen (oder von dieser als Ziel ausgewählt werden), im Cache gespeichert werden. Der Cache-Index wird aktualisiert, wenn sich die physischen Adressen der Daten im Cache ändern. Beispielsweise kann die tatsächliche physikalische Adresse (z. B. die Segment-ID und der Versatz) von Daten, die einer logischen Cache-Adresse (z. B. Benutzerblock) entsprechen, aktualisiert werden, wenn sich der physikalische Ort der Daten, die den logischen Cache-Adressen zugeordnet sind, ändert (z. als Ergebnis eines Speicherbereinigungsprozesses, wie oben beschrieben).
  • In einer Implementierung umfasst die direkte Cache-Adressübersetzungsdatenstruktur eine Hash-Tabelle. In einer Implementierung ordnet die Hash-Tabelle für jede von mehreren logischen Blockadressen die logische Blockadresse (z. B. Datenträger-ID und Offset, Benutzereingabeadresse oder Hostadresse) direkt einer jeweiligen physischen Adresse (z. B. Segment) zu ID und Offset) für einen physischen Speicherort in einem Cache, wobei die beiden Baumspaziergänge des mehrstufigen Übersetzungsindex durch eine einzelne Hash-Tabellensuche ersetzt werden. Die Hash-Tabelle, die als Beschleunigungsindex dient, kann als „Metadaten-Bypass-Cache“ betrachtet werden, der im Cache-Datenortungssystem verwendet wird, um die Adressierung des Speichersystems in der SCM-Cache-Schicht zu erleichtern, ohne die CPU-Kosten für interne Metadaten-Lookups zu verursachen (z. B. durch Umgehen) eine Suche nach einer logischen Cache-Adresse in Metadaten).
  • In einer Implementierung kann ein Schlüssel für eine Suche in der Hash-Tabelle auf der logischen Blockadresse für Zieldaten basieren. Beispielsweise kann eine Hash-Funktion auf die logische Blockadresse angewendet werden, um einen „Hash“ der logischen Blockadresse zu erzeugen oder zu erhalten. Der Hash oder Teile des Hash können als Schlüssel zum Ausführen einer Suche in der Hash-Tabelle dienen. Beispielsweise kann ein Teil des Hashs der logischen Blockadresse (z. B. der Hash ohne die letzten 4 Bits des Hashs) als erster Schlüssel in der Hash-Tabelle verwendet werden, um eine Seite zu identifizieren, die einen Eintrag enthält, der den physischen Kandidaten enthält Adresse für einen Kandidaten für einen physischen Standort (z. B. der die Zieldaten enthalten kann). Der vollständige Hash kann als zweiter Schlüssel in der Hash-Tabelle verwendet werden, um einen bestimmten Ort auf der identifizierten Seite für den Eintrag zu identifizieren, der die physikalische Adresse des Kandidaten enthält.
  • In einer Implementierung umfasst die Hash-Tabelle eine zweistufige Tabelle, die ein Array von Zeigern auf Seiten mit Einträgen für den Schlüssel / Kandidaten-Standort (K / CPL) auf jeder Seite umfasst. In einer Implementierung darf jede Seite eine Größe von nicht mehr als 10 MB haben und wobei die Seiten mindestens 200.000 Seiten umfassen. In einer Implementierung ist jede Seite 1 MB groß, wobei die Hash-Tabelle 500.000 Seiten umfasst. In einer Implementierung umfasst jede Seite nicht mehr als 50.000 K / CPL-Einträge. Jeder K / CPL-Eintrag kann eine logische Blockadresse (z. B. über einen Hash der logischen Blockadresse) einer physischen Kandidatenadresse in dem Eintrag zuordnen. In einer Implementierung umfasst jede Seite 32.000 K / CPL-Einträge.
  • In solchen Implementierungen kann die Größe der Seiten (nicht größer als 10 MB und bei einigen Implementierungen 1 MB) von einem Speicherzuweiser effizient verwaltet werden. Wenn ein einheitlicher Allokator beispielsweise Speicher zurückfordern soll, werden Seiten möglicherweise verworfen, während nur ein kleiner Teil der Hash-Tabelle verloren geht. Außerdem kann für jede Seite eine separate Sperre (z. B. eine Drehsperre) implementiert werden. In solchen Implementierungen treten die meisten Zugriffe bei einer Sperre nicht in Konflikt, da eine Anzahl von Seiten groß ist. In solchen Beispielen kann jede Seite mit einer Sperre geschützt sein, z. B. einer Drehsperre, aber die Wahrscheinlichkeit eines Sperrkonflikts für gleichzeitige Threads kann vernachlässigbar sein. Gleichzeitig ist number die Anzahl der Einträge auf einer Seite hoch, so dass der Speicherplatzaufwand für eine solche Sperre minimal ist. Eine solche Dimensionierung kann die Einbeziehung aller Einträge für eine große Eingabe / Ausgabe (IO) unter nur einer Sperre erreichen. Beispielsweise kann eine einzelne Sperre jeden Eintrag einer Seite schützen (z. B. 32.000 Einträge). Infolgedessen können solche Implementierungen eine granulare Seitensperrung bereitstellen, die effizient ist und eine hohe Parallelität ermöglicht.
  • In einer Implementierung wird ein Hash der logischen Blockadressen mit den ausgeblendeten niedrigen vier Bits als Schlüssel zum Auswählen einer Seite verwendet, sodass benachbarte logische Blockadressen (LBAs) auf derselben Seite landen. Innerhalb jeder Seite wird ein Array von Schlüssel- / CPL-Werten durch den (vollständigen) Hash der logischen Blockadressen als Schlüssel indiziert. In einem Beispiel ist die Hash-Tabelle assoziativ in vier Richtungen gesetzt, was bedeutet, dass für jeden Schlüssel vier mögliche Slots vorhanden sind. Diese Anordnung kann einen hohen Lastfaktor mit niedrigen und deterministischen Prüfkosten bereitstellen. Die Leistung kann verbessert werden, da alle möglichen Speicherorte für ein Element im Speicher zusammenhängend sind und in zwei CPU-Cache-Zeilen passen können.
  • In einer Implementierung dient der Ort des Eintritts in den Satz als Proxy für seine Temperatur. In einer solchen Implementierung werden die Einträge in der Menge in einer Reihenfolge der zuletzt verwendeten (LRU) verwaltet, indem neue und aufgerufene Einträge an das obere oder zuletzt verwendete (MRU) Ende der Gruppe heraufgestuft und der Eintrag am unteren Rand entfernt werden oder LRU-Ende des Satzes (der zuletzt verwendete Eintrag im Satz), wenn ein neuer Eintrag in einen vollständigen Satz eingefügt wird. Infolgedessen wird die Position im Set als Indikator für die Temperatur des Eintrags verwendet. Somit kann die LRU-Cache-Richtlinie mit geringem oder keinem Speicherplatzaufwand angenähert werden.
  • Obwohl die Verwendung einer Hash-Tabelle zum Implementieren der direkten Adressübersetzungsdatenstruktur in einigen Beispielen zu Kollisionen und Räumungen führen kann, die bei einem hohen Auslastungsfaktor nicht behoben werden können, behebt die zusätzliche Einbeziehung des mehrstufigen Übersetzungsindex solche Bedenken. Da die direkte Adressübersetzungsdatenstruktur selbst ein Cache ist, sind Fehlschläge akzeptabel, da sie durch einen Datenübersetzungspfad durch den mehrstufigen Adressübersetzungsindex behoben werden, wenn auch mit einer etwas höheren Latenz.
  • Offenbart ist ein Beispielsystem , das persistent persistente Speichergeräte, Cache-Geräte mit geringer Latenz, flüchtigen Speicher und mindestens einen Prozessor enthalten kann. Der Prozessor soll Anweisungen ausführen, um eine direkte Adressübersetzungsdatenstruktur in dem flüchtigen Speicher zu speichern, die verwendet werden kann, um eine logische Blockadresse für Zieldaten direkt in eine physische Kandidatenadresse eines physischen Kandidatenorts auf dem Cache-Gerät zu übersetzen, und eine mehrstufige Übersetzung zu speichern Index im flüchtigen Speicher zum Übersetzen der logischen Blockadresse für die Zieldaten in eine tatsächliche physikalische Adresse für einen erwarteten physischen Ort, der die Zieldaten auf dem Cache-Gerät enthält, und Bestimmen, ob sich die Zieldaten an dem dem Kandidaten entsprechenden physischen Ort des Kandidaten befinden physikalische Adresse, die aus der Datenstruktur der direkten Cache-Adressübersetzung abgerufen wird. In Reaktion auf die Zieldaten, die sich am physischen Standort des Kandidaten befinden, kann der Prozessor Anweisungen ausführen, um auf die Zieldaten am physischen Standort des Kandidaten zuzugreifen. In Reaktion auf die Zieldaten, die sich nicht an der physischen Adresse des Kandidaten befinden, kann der Prozessor Anweisungen ausführen, um auf die Zieldaten an dem erwarteten physischen Ort zuzugreifen, der aus dem mehrstufigen Übersetzungsindex abgerufen wird.
  • Beschrieben wird ein Beispiel Verfahren das umfasst eine Datenstruktur in einem flüchtigen Speicher zu speichern , die direkt für die gezielte Daten an eine Kandidaten physikalische Adresse eines Kandidaten physikalischen Position auf einer Cache - Einheit einen Block logische Adresse übersetzt, ein mehrstufiges Übersetzungs Speichern Index in dem flüchtigen Speicher, der verwendet werden kann, um die logische Blockadresse für die Zieldaten in eine tatsächliche physikalische Adresse für den erwarteten physischen Ort auf dem Cache-Gerät zu übersetzen; und Bestimmen, ob sich die Zieldaten an dem physischen Kandidatenort befinden, der der physischen Kandidatenadresse entspricht, die aus der direkten Cache-Adressübersetzungsdatenstruktur abgerufen wurde. In Reaktion auf die Zieldaten, die sich nicht an der physischen Adresse des Kandidaten befinden, wird auf die Zieldaten an dem erwarteten physischen Ort zugegriffen, der einer tatsächlichen physischen Adresse entspricht, die aus dem mehrstufigen Übersetzungsindex abgerufen wurde. Darüber hinaus Übersetzung Struktur die erwartete physikalische Position aus dem Multi - Level - Übersetzung Index abgerufen wird in der direkten Cache Adreßumsetzungsstruktur zwischengespeichert, was zu einer automatischen Aktualisierung des direkter Cache - Adresse.
  • Offenbart ist ein Beispiel für ein nicht vorübergehendes computerlesbares Medium, das Anweisungen für einen Prozessor enthält. Die Anweisungen können vom Prozessor ausgeführt werden, um einen Prozessor anzuweisen, eine logische Blockadresse für Zieldaten zu empfangen, die empfangene logische Blockadresse unter Verwendung einer direkten Cache-Adressübersetzungsdatenstruktur direkt in eine physikalische Kandidatenadresse zu übersetzen und zu bestimmen, ob sich die Zieldaten bei a befinden physischer Speicherort des Kandidaten in einem Cache, der der physischen Adresse des Kandidaten entspricht. In Reaktion auf die Zieldaten, die sich am physischen Standort des Kandidaten befinden, können die Anweisungen vom Prozessor ausgeführt werden, um auf die Zieldaten am physischen Standort des Kandidaten zuzugreifen. In Reaktion auf die Zieldaten, die sich nicht am physischen Standort des Kandidaten befinden, sollen die Anweisungen den Prozessor anweisen, einen mehrstufigen Übersetzungsindex zu verwenden, um die logische Blockadresse in eine logische Cache-Adresse zu übersetzen, die logische Cache-Adresse in eine tatsächliche physische Adresse zu übersetzen und Zugriff auf die Zieldaten an der tatsächlichen physischen Adresse (z. B. einem erwarteten physischen Speicherort im Cache, der der tatsächlichen physischen Adresse entspricht). In einigen Implementierungen verwenden die Anweisungen ferner die Ergebnisse aus dem mehrstufigen Übersetzungsindex, um die Datenstruktur der direkten Cache-Adressübersetzung automatisch zu aktualisieren.
  • 1 ist ein Blockdiagramm, das schematisch Teile eines beispielhaften Cache- Datenlokalisierungssystems 20 darstellt. 20 System kann die Zeit reduzieren , verbraucht zu lokalisieren und Zugriff auf Daten auf einem Cache gespeichert. Das System 20 kann die Zeit reduzieren, die für den Zugriff auf im Cache gespeicherte Daten benötigt wird, indem die Zeit zum Identifizieren des physischen Speicherorts von Daten im Cache verringert wird. System 20 umfasst persistente Speichervorrichtung (en) 24 mit niedriger Latenz Cache - Einheit (en) 28, einen flüchtigen Speicher 32, und mindestens einen Prozessor 36
  • Persistente Speichervorrichtungen 24 umfassen eine oder mehrere nichtflüchtige Speichervorrichtungen zum Speichern von Daten, auf die zugegriffen, abgerufen oder daraus gelesen werden soll. Persistente Speichervorrichtungen 24 umfassen ferner einen Bereich, in den Daten kopiert oder geschrieben werden können. In den hier beschriebenen Beispielen können persistente Speichervorrichtungen (wie persistente Speichervorrichtungen 24) durch Festplattenlaufwerke (HDD (s)), Solid-State-Laufwerke (s) (SSDs) implementiert werden.) (z. B. Flash-Speichervorrichtung (en)) oder dergleichen oder eine Kombination davon.
  • Die Cache-Vorrichtung 28 mit niedriger Latenz umfasst eine Speichervorrichtung, die Kopien von mindestens einigen der Daten (schematisch in gestrichelten Linien dargestellt) speichert, die auch auf persistenten Speichervorrichtungen 24 gespeichert sind. Die Cache-Vorrichtung 28 mit niedriger Latenz hat eine Latenz oder Antwortzeit, die geringer ist als die der persistenten Speichervorrichtung (en) 24. Infolgedessen erleichtert die Cache-Vorrichtung 28 mit niedriger Latenz den zeitnahen Zugriff auf Kopien von Daten. In einer Implementierung umfasst die Cache-Vorrichtung 28 mit niedriger Latenz eine persistente Speichervorrichtung (en) mit geringer Latenz oder nichtflüchtige Speichervorrichtung (en). In einer Implementierung umfasst das Cache-Gerät 28 mit niedriger Latenz ein oder mehrere Speicherklassenspeichergeräte (SCM-Geräte). In den hier beschriebenen Beispielen kann SCM eine Art nichtflüchtiger Speicher (NVM) sein. In einigen Beispielen kann SCM unter Verwendung eines Protokolls kommunizieren, das mit NVM Express ™ (NVMe ™) konsistent ist. In den hier beschriebenen Beispielen kann eine SCM-Vorrichtung in einer von mehreren verschiedenen Formen implementiert sein, wie beispielsweise einem 3D-XPoint-Chip (oder einer 3D-XPoint-DIMM-Vorrichtung, einer PCM-Vorrichtung (Phase Change Memory) (z als Phase-Change-Direktzugriffsspeicher (RAM), Magnetic RAM (MRAM) (wie Spin-Torque-Transfer (STT) RAM), Resistive RAM (RRAM), Memristor oder wie oder eine Kombination davon. In einigen Beispielen kann der SCM einen blockbasierten Zugriff implementieren. In anderen Beispielen kann SCM eine speicherbasierte Semantik für den Datenzugriff implementieren. In einer Implementierung umfassen persistente Speichervorrichtungen 24 eine Festplatte oder ein Solid-State-Laufwerk mit einer Antwortzeit für eine gegebene Datenmenge von etwa 10.000 us. Im Vergleich dazu hat die Cache-Vorrichtung 28 mit niedriger Latenz in Form eines SCM eine Antwortzeit für die gleichen Daten von ungefähr 10 us. In einigen Beispielen kann ein Cache-Gerät mit niedriger Latenz ein byteadressierbares nichtflüchtiges Speichergerät sein. In einigen Beispielen kann eine persistente Speichervorrichtung eine blockadressierbare nichtflüchtige Speichervorrichtung sein.
  • Der flüchtige Speicher 32 ist insofern flüchtig, als der nichtflüchtige Datenspeicher 32 verloren geht, wenn dem Speicher 32 längere Zeit keine Energie zugeführt wird. In einer Implementierung umfasst der flüchtige Speicher 32 einen Direktzugriffsspeicher, wie beispielsweise einen dynamischen Direktzugriffsspeicher (DRAM). Der flüchtige Speicher 32 kann eine Antwortzeit haben, die geringer ist als die der Cache-Vorrichtung 28 mit niedriger Latenz. In einer Implementierung hat die Cache-Vorrichtung 28 mit niedriger Latenz in Form eines SCM eine Antwortzeit von 10 us für die gegebene Datenmenge, während der flüchtige Speicher in Form eines DRAM eine Antwortzeit für die gleiche gegebene Datenmenge von hat ungefähr 0,1 us.
  • Der Prozessor 36 verwaltet den Zugriff auf Daten auf dem Cache-Gerät 28 mit geringer Latenz. Der Prozessor 36 kann in Form einer anwendungsspezifischen integrierten Schaltung oder einer anderen Verarbeitungseinheit (z. B. physikalische Hardware) vorliegen, die Anweisungen, Code, Programmierung oder Schaltungslogik ausführt, um den Zugriff auf Daten der Cache-Vorrichtung 28 mit niedriger Latenz zu verwalten. Die Anweisungen oder Schaltungslogik , dass Antriebsprozessor 36 Ursache Prozessor 36 40 eine direkte cache Adreßübersetzung Datenstruktur zum Speichern von in dem flüchtigen Speicher 32. In einer Implementierung ordnet die direkte Adressübersetzungsdatenstruktur 40 logische Blockadressen (z. B. jeweils eine Volumen-ID und einen Versatz) direkt einer jeweiligen physischen Kandidatenadresse (z. B. Segment-ID und Versatz) für Daten zu, auf die abgezielt werden soll.
  • Da die Adressumsetzung direkt ist (anstatt mehrere Tabellen oder Bäume zu durchlaufen), kann die Datenstruktur 40 ein viel schnelleres und reaktionsschnelleres Auffinden einer physischen Adresse ermöglichen, auf die vom Benutzer angeforderte Daten zugreifen können. In Implementierungen, in denen die Daten, auf die zugegriffen wird, auf der Cache-Vorrichtung mit niedriger Latenz gespeichert sind, wie beispielsweise einer SCM-Speichervorrichtung, reduziert die Verwendung der direkten Adressübersetzungstabelle 40 die Zeit oder die Kosten, die mit dem Auffinden der physischen Adresse der Daten verbunden sind, den Engpass in die Gesamtzeit für den Zugriff auf die Daten. In einer Implementierung kann die direkte Cache-Adressübersetzungsdatenstruktur 40 eine Hash-Tabelle umfassen. Beispielsweise kann eine Hash-Funktion auf die logische Blockadresse angewendet werden, wobei der resultierende Hash als Schlüssel für eine Suche oder Lookups in der Hash-Tabelle dient. In anderen Implementierungen kann die direkte Adressübersetzungsdatenstruktur 40 andere Datenstrukturen wie einen Suchbaum umfassen.
  • Die Anweisungen oder die Schaltungslogik, die den Prozessor 36 ansteuern, bewirken auch, dass der Prozessor 36 einen mehrstufigen Adressübersetzungsindex 44 in einem flüchtigen Speicher 32 speichert. Der mehrstufige Adressübersetzungsindex 44 kann als autorisierende (dh aktuelle) Sicherung dienen, wenn die Verwendung der weniger autorisierenden direkten Adressübersetzungsdatenstruktur 40 nicht erfolgreich ist, beispielsweise wenn die physikalische Adresse der vom Benutzer im Cache angeforderten Daten Die Vorrichtung 28 hat sich geändert und die direkte Cache-Adressübersetzungsdatenstruktur 40 wurde noch nicht aktualisiert, um die Änderung widerzuspiegeln. Der mehrstufige Übersetzungsindex 44 ist im Vergleich zu der direkten Adressübersetzungsdatenstruktur 40 „autoritativer“, da der mehrstufige Übersetzungsindex 44 in Bezug auf den physischen Ort der Zieldaten im Cache aufgrund dessen aktueller oder aktueller sein kann zu einer häufigeren Aktualisierung des mehrstufigen Übersetzungsindex 44 mit den erwarteten physischen Speicherorten von Daten im Cache 28 (da diese Daten an verschiedene Speicherorte im Cache 28 verschoben werden) im Vergleich zu der direkten Cache-Adressübersetzungsdatenstruktur 40. Ein Beispiel eines solchen mehrstufigen Übersetzungsindex 44 ist ein Index, der eine erste Ebene enthält, die einen Blockindex umfasst, der einen Baum umfasst, der logische Blockadressen (z. B. jeweils eine Volumen-ID und einen Offset) (die logische Blockadresse) der jeweiligen logischen Cache zuordnet Adresse (z. B. eine entsprechende Benutzerblockkennung). Der Index umfasst ferner eine zweite Ebene, die einen Cache-Index umfasst, der einen Baum umfasst, der die logischen Cache-Adressen den jeweiligen tatsächlichen physischen Adressen im Cache (z. B. jeweils eine Segment-ID und einen Versatz) zuordnet, die zum physischen Lokalisieren der Daten im Cache verwendet werden können. Der Cache-Index wird aktualisiert, wenn sich die jeweiligen physischen Adressen der Daten im Cache ändern.
  • 2 ist ein Blockdiagramm, das Teile eines beispielhaften nichtflüchtigen computerlesbaren Mediums 60 darstellt, das Anweisungen enthält, die von einem Prozessor wie dem Prozessor 36 ausgeführt werden können, um den Zugriff auf Daten zu verwalten, die in einem Cache mit geringer Latenz gespeichert sind (z. B. von einer Cache-Vorrichtung implementiert) (s), wie z. B. Gerät (e) 28). In einer Implementierung folgt der Prozessor 36 den Anweisungen, die in dem Speicher 60 enthalten sind. 3 ist ein Flussdiagramm eines beispielhaften Verfahrens 100, das vom System 20 mit dem Prozessor 36 gemäß den Anweisungen im Speicher (oder einem anderen maschinenlesbaren Speichermedium) 60 ausgeführt werden kann. Es versteht sich, dass der Speicher 60 mit Cache-Datenlokalisierungssystemen 20 verwendet werden kann. Ebenso kann das Verfahren 100 mit einem der folgenden beschriebenen Cache-Datenlokalisierungssysteme oder einem ähnlichen Speichersystem ausgeführt werden.
  • Wie in 2 gezeigt, umfasst der Speicher 60 direkte Übersetzungsdatenstrukturbefehle 64, mehrstufige Übersetzungsindexbefehle 68 und Adresszugriffsbefehle 72. Anweisungen 64 umfassen Programmierung, Code oder Logik - Schaltung , dass die direkte Prozessor 36 auszuführen Block 104 des Verfahrens 100 in 3 gezeigt ist. Insbesondere weisen die Anweisungen 64 den Prozessor 36 an, eine Datenstruktur wie die Datenstruktur 40 in einem flüchtigen Speicher wie dem flüchtigen Speicher 32 zu speichern, der logische Blockadressen direkt in jeweilige physikalische Kandidatenadressen für jeweilige physikalische Kandidatenorte in einem Cache übersetzt Gerät, wie Cache-Gerät (e) 28, wie oben beschrieben. In einer Implementierung sind Anweisungen 64 ausführbar, um eine direkte Übersetzungsdatenstruktur 40 in Form einer Hash-Tabelle (wie oben beschrieben) in einem flüchtigen Speicher 32 einzurichten, zu erstellen und zu speichern.
  • Mehrstufige Übersetzungsindexbefehle 68 umfassen Programmier-, Code- oder Schaltungslogik, die an den Direktprozessor 36 ausführbar ist, um den in 3 gezeigten Block 108 des Verfahrens 100 auszuführen. Anweisungen 68 direkter Prozessor 36 zum Erstellen, Speichern und Verwalten eines mehrstufigen Übersetzungsindex, wie beispielsweise des Index 44, in einem flüchtigen Speicher 32 zum Übersetzen von logischen Blockadressen in jeweilige tatsächliche physikalische Adressen für jeweilige erwartete physikalische Orte auf Cache-Geräten 28, wie beschrieben über. Wie oben beschrieben wurde, bei einigen Implementierungen, die Mehrebenen - Übersetzung Index 44 erstellt und kann einer ersten Ebene umfassen gespeichert, der einen Blockindex weist einen Baum umfasst, dass die Karten sperren logischen Adressen (zB, die jeweils eine ID Volumen und Offset) zu einem jeweiligen logische Cache-Adresse (z. B. ein entsprechender Benutzerblock). Der Index 44 umfasst ferner eine zweite Ebene mit einem Cache-Index, der einen Baum umfasst, der die logischen Cache-Adressen den jeweiligen tatsächlichen physischen Adressen (z. B. jeweils einer Segment-ID und einem Offset) zuordnet, die zum physischen Lokalisieren von Daten im Cache verwendet werden können. Der Cache-Index wird aktualisiert, wenn sich die physische Adresse bestimmter Daten im Cache ändert.
  • Adressenzugriffsanweisungen 72 umfassen Programmierung, Code oder Logik - Schaltung ausführbar direkten Prozessor 36-112 Blöcke durchzuführen, 114 und 116 des Verfahrens 100 in 3. Wie durch Block 112 angegeben, leiten als Antwort auf den Prozessor 36, der eine logische Blockadresse 50 empfängt (in 1 gezeigt), die Adresszugriffsanweisungen 72 den direkten Prozessor 36, um zuerst zu bestimmen, ob die Daten, auf die die logische Blockadresse 50 abzielt, bei dem physischen Kandidaten liegen Adresse, die aus der direkten Cache-Adressübersetzungsdatenstruktur abgerufen wurde. Um eine solche Bestimmung vorzunehmen, weist der direkte Prozessor 36 die Anweisung 70 an, die physikalische Kandidatenadresse für die Zieldaten aus der direkten Cache-Adressübersetzungsdatenstruktur 40 abzurufen. In einer Implementierung, in der die direkte Cache-Adressübersetzungsdatenstruktur 40 eine Hash-Tabelle umfasst, kann ein Hash der logischen Blockadresse (oder Teile davon) als Schlüssel für die Hash-Tabelle (wie oben beschrieben) dienen, um eine physikalische Kandidatenadresse für zu erhalten das Datenelement im Cache 28. Beispielsweise ordnet die Hash-Tabelle in einer Implementierung einen Hash der logischen Blockadresse (die Volume-ID und den Offset) direkt der Segment-ID und dem Offset (dem physischen Standort oder der Adresse des Kandidaten) zu, wobei die beiden Baumspaziergänge des ersetzt werden Mehrebenen-Übersetzungsindex mit einer einzelnen Hash-Tabellensuche. Die Hash-Tabelle, die als Beschleunigungsindex dient, ist ein Metadaten-Bypass-Cache, der im Speichersystem verwendet wird, um die Adressierung des Speichersystems in der SCM-Cache-Schicht zu erleichtern, ohne die CPU-Kosten für interne Metadaten-Lookups zu verursachen.
  • Sobald die physikalische Standortadresse des Kandidaten abgerufen wurde, wird bestimmt, ob sich die Zieldaten am physischen Standort des Kandidaten befinden. In einer Implementierung erfolgt die Bestimmung durch Vergleichen von zwei Kennungen. In einer Implementierung hat jeder physische Ort im Cache eine erste Kennung gespeichert, die direkt mit den zugewiesenen Daten verknüpft ist und sich mit diesen bewegt. Der Eintrag in der Datenstruktur für die direkte Cache-Adressübersetzung, die die logische Blockadresse mit dem physischen Standort des Kandidaten verknüpft, enthält eine zweite Kennung, die den Daten zugeordnet ist, von denen angenommen wird, dass sie sich am physischen Standort des Kandidaten befinden. Wenn die direkte Cache-Adressübersetzungsdatenstruktur zum ersten Mal mit der zweiten Kennung gefüllt wird, ist die zweite Kennung dieselbe wie die erste Kennung, die am physischen Standort des Kandidaten gespeichert ist. Sobald die Daten jedoch an einen neuen Speicherort verschoben wurden, beispielsweise aufgrund des oben beschriebenen Speicherbereinigungsprozesses, kann der physische Speicherort des Kandidaten frei von Daten und einer Kennung sein oder tatsächlich andere Daten mit einer anderen Kennung als speichern die Kennung, die der logischen Blockadresse zugeordnet und zuvor in der Datenstruktur für die direkte Cache-Adressübersetzung gespeichert wurde. Ein Vergleich der beiden Bezeichner zeigt an, ob sich die der logischen Blockadresse zugeordneten Daten tatsächlich an der Kandidatenadresse befinden. Wenn die beiden Kennungen übereinstimmen, sind die Daten am physischen Standort des Kandidaten die Zieldaten, die durch die logische Blockadresse identifiziert werden, und auf die Zieldaten kann zugegriffen werden. Wenn die beiden Kennungen nicht übereinstimmen, sind die Daten am physischen Standort des Kandidaten nicht die Zieldaten, die durch die logische Blockadresse identifiziert werden.
  • Wie durch Block 116 in Verfahren 100 angegeben, Adressantwortzugriff auf die Zieldaten, die sich nicht am physischen Standort des Kandidaten befinden, wie z. B. den physischen Standort des Kandidaten, der keine Daten enthält oder andere Daten enthält als die Zieldaten, die der logischen Blockadresse entsprechen Die Anweisungen 72 weisen den Prozessor 36 an, auf den physischen Ort oder die Adresse zuzugreifen, die der logischen Blockadresse entsprechen, die aus dem mehrstufigen Übersetzungsindex 44 abgerufen wird. Insbesondere führt der Prozessor 36 eine erste Baumsuche in einem Blockindex durch, der die logische Blockadresse (eine Volumen-ID und einen Versatz) einem Benutzerblock (der die erste Kennung sein kann) zuordnet. Die Anweisungen 72 weisen dann den Prozessor 36 an, eine zweite Baumsuche in einem Cache-Index durchzuführen, der den Benutzerblock einer Segment-ID und einem Offset (der erwarteten physischen Adresse oder Position in Cache 28) zuordnet, die zum physischen Lokalisieren der Zieldaten verwendet werden können im Cache 28.
  • 4 ist ein Blockdiagramm, das schematisch Teile eines beispielhaften Cache- Datenortungssystems 220 darstellt. Das System 220 ist dem oben beschriebenen System 20 ähnlich, mit der Ausnahme, dass das System 220 speziell persistente Speichervorrichtungen 224 in Form von mindestens einer SSD, mindestens einer Festplatte oder einer Kombination davon, einer Cache-Vorrichtung 228 mit niedriger Latenz in der Form, umfasst des Speicherklassenspeichercaches, eines flüchtigen Speichers 232 in Form eines DRAM, einer direkten Adressübersetzungsdatenstruktur 240 in Form einer Hash-Tabelle und eines mehrstufigen Adressübersetzungsindex 244 in Form eines Index mit einem Blockindex 252 und ein Cache-Index 254. Die übrigen Komponenten des Systems 220, die den Komponenten des Systems 20 entsprechen, sind ähnlich nummeriert. In einigen Implementierungen kann die persistente Speichervorrichtung 224 ein Festplattenlaufwerk oder eine Kombination aus einem Solid-State-Laufwerk und einem Festplattenlaufwerk umfassen. Wie oben beschrieben, umfasst der Blockindex 252 einen Baum, der eine Volumen-ID abbildet und einem Benutzerblock versetzt. Der Cache-Index umfasst einen Baum, der den Benutzerblock einer Segment-ID und einem Offset zuordnet, die zum physischen Lokalisieren der Daten im Cache verwendet werden können. Der Cache-Index 254 wird aktualisiert, wenn sich die physikalische Adresse bestimmter Daten im Cache ändert.
  • 5 ist ein Flussdiagramm eines beispielhaften Cache-Datenlokalisierungsverfahrens 300. Das Verfahren 300 wird im Zusammenhang mit der Ausführung durch das System 220 beschrieben. Es versteht sich, dass das Verfahren 300 durch eines der hier beschriebenen Systeme oder durch andere ähnliche Speichersysteme beschrieben werden kann.
  • Wie durch Block 304 angegeben, empfängt das Cache-Datenortungssystem 220 eine Anforderung von einem Benutzer, auf eine Kopie der im Speicher 228 gespeicherten Daten zuzugreifen. Das System 220 empfängt eine logische Blockadresse oder eine Hostadresse. In einer Implementierung umfasst die logische Blockadresse eine Volumen-ID und einen Offset oder entspricht dieser.
  • Wie durch Block 308 angegeben, bestimmt oder identifiziert der Prozessor 36 gemäß den Anweisungen, wie den Anweisungen, die in dem oben beschriebenen Speicher 60 enthalten sind, eine Kandidatenadresse für die Daten, auf die die logische Blockadresse abzielt, unter Verwendung der Hash-Tabelle der direkten Cache-Adressübersetzungsdatenstruktur. Mit anderen Worten versucht der Prozessor 36, die physikalische Adresse im Cache 228, die der logischen Blockadresse entspricht, unter Verwendung der direkten Adressübersetzungs-Hash-Tabelle 240 zu identifizieren. Die Hash-Tabelle 240 für die direkte Adressumsetzung stellt eine direkte Übersetzung von der logischen Blockadresse zur physischen Adresse im Cache 228 bereit. Insbesondere wird eine Hash-Funktion auf die logische Blockadresse angewendet, wobei der resultierende Hash als Schlüssel dient, um eine Suche in der Hash-Tabelle nach dem physischen Standort des Kandidaten für die Zieldaten durchzuführen. In einer Implementierung wird die direkte Adress-Hash-Tabelle verwendet, um die Volumen-ID und den Versatz (logische Blockadresse oder logische Blockadresse) in eine Segment-ID und einen Versatz (den physischen Kandidatenort) des Cache 228 ohne mehrere Baumindex-Suchvorgänge zu übersetzen.
  • Wie durch Block 310 angegeben, bestimmt der Prozessor 36 gemäß den Anweisungen, die den Speicher 60 enthalten, ob die in Block 308 verwendete direkte Cache-Adressübersetzungsdatenstruktur eine physikalische Kandidatenadresse identifiziert hat, die der logischen Blockadresse entspricht (z. B. wo sich das angeforderte Datenelement befindet gespeichert) wurde gefunden. Beispielsweise können unter Umständen, in denen die physikalische Adresse des bestimmten Zieldatenstücks oder der Kopie der Daten im Cache 228 verschoben wurde, die Zieldaten möglicherweise nicht tatsächlich an dem physischen Kandidatenort liegen, der aus der direkten Cache-Adressübersetzungsdatenstruktur erhalten wird.
  • In einer Implementierung erfolgt die Bestimmung durch Vergleichen von zwei Kennungen. In einer Implementierung hat jeder physische Ort im Cache eine erste Kennung gespeichert, die direkt mit den zugewiesenen Daten verknüpft ist und sich mit diesen bewegt. Der Eintrag in der Datenstruktur für die direkte Cache-Adressübersetzung, die die logische Blockadresse mit dem physischen Standort des Kandidaten verknüpft, enthält eine zweite Kennung, die den Daten zugeordnet ist, von denen angenommen wird, dass sie sich am physischen Standort des Kandidaten befinden. Wenn die direkte Cache-Adressübersetzungsdatenstruktur zum ersten Mal mit der zweiten Kennung gefüllt wird, ist die zweite Kennung dieselbe wie die erste Kennung, die am physischen Standort des Kandidaten gespeichert ist. Sobald die Daten jedoch an einen neuen Speicherort verschoben wurden, beispielsweise aufgrund des oben beschriebenen Speicherbereinigungsprozesses, kann der physische Speicherort des Kandidaten frei von Daten und einer Kennung sein oder tatsächlich andere Daten mit einer anderen Kennung als speichern die Kennung, die der logischen Blockadresse zugeordnet und zuvor in der Datenstruktur für die direkte Cache-Adressübersetzung gespeichert wurde. Ein Vergleich der beiden Bezeichner zeigt an, ob sich die der logischen Blockadresse zugeordneten Daten tatsächlich an der Kandidatenadresse befinden. Wenn die beiden Kennungen übereinstimmen, sind die Daten am physischen Standort des Kandidaten die Zieldaten, die durch die logische Blockadresse identifiziert werden. Wenn die beiden Kennungen nicht übereinstimmen, sind die Daten am physischen Standort des Kandidaten nicht die Zieldaten, die durch die logische Blockadresse identifiziert werden.
  • Wie durch Block 314 angezeigt, greift der Prozessor 36 auf die physikalische Adresse auf der Cache-Vorrichtung 228 zu, wenn die korrekte physikalische Adresse der angeforderten Daten (basierend auf der logischen Blockadresse) gefunden wurde. Ein solcher Zugriff kann das Lesen von Daten von der bestimmten physischen Adresse oder das Schreiben von Daten an die bestimmte physische Adresse umfassen.
  • Alternativ führt, wie durch Block 316 angegeben, der Prozessor 36 in Reaktion auf das in Block 308 ausgeführte Cache-Datenlokalisierungsverfahren, das die korrekte physikalische Adresse für die angeforderten Daten nicht identifiziert, gemäß der im Speicher 60 enthaltenen Anweisung eine mehrstufige Übersetzungsindexsuche 320 durch . Wie durch Block 322 angegeben, führt der Prozessor 36 eine erste Baumsuche in einem Blockindex durch, der die Benutzereingabe (eine Volumen-ID und einen Versatz) einem Benutzerblock zuordnet. Wie durch Block 324 angegeben, führt der Prozessor 36 eine zweite Baumsuche in einem Cache-Index durch, der den Benutzerblock einer Segment-ID und einem Offset (der physischen Adresse in Cache 28) zuordnet, die verwendet werden können, um einen erwarteten physischen Ort für die Zieldaten zu identifizieren auf dem Cache 28 pro Block 314.
  • Wie durch Block 322 angegeben, wird der erwartete physikalische Ort, der aus der mehrstufigen Übersetzungsindexsuche 320 abgerufen wird, in der Hash-Tabelle zwischengespeichert. Infolgedessen wird die Datenstruktur der direkten Cache-Adressübersetzung automatisch mit Adressinformationen aus dem häufiger aktualisierten mehrstufigen Übersetzungsindex aktualisiert, wenn Fehler in Block 308 gefunden werden.
  • 6 ist ein Flussdiagramm eines beispielhaften Cache-Datenlokalisierungsverfahrens 400 zum Lokalisieren von Daten in einem Cache. Obwohl das Verfahren 400 im Zusammenhang mit der Ausführung durch das System 220 (oben in Bezug auf 4 gezeigt und beschrieben) beschrieben ist, kann das Verfahren 400 ebenfalls durch das System 20 oder andere ähnliche Cache-Datenlokalisierungssysteme oder ähnliche Speichersysteme ausgeführt werden. Die Blöcke des Verfahrens 400 können vom Prozessor 36 gemäß den Anweisungen ausgeführt werden, die auf einem nicht vorübergehenden computerlesbaren Medium gespeichert sind. In einer Implementierung kann das Verfahren 400 von einem Prozessor ausgeführt werden, der dem Befehl folgt, der in einem nicht vorübergehenden computerlesbaren Medium oder Speicher enthalten ist, wie beispielsweise dem Speicher 60, wobei der Befehl 64, 68 und 72 den Prozessor 36 zum Ausführen des Verfahrens 400 auffordert.
  • Wie durch den Block 404 angedeutet, Cachedatenlokalisierungssystem 220 empfängt eine Anforderung von einem Benutzer für den Zugriff gezielt in Speicher 228 gespeicherten Daten. Das System 220 empfängt eine logische Blockadresse, die manchmal auch als Hostadresse oder logische Blockadresse (BLA) bezeichnet wird. Die logische Blockadresse unterscheidet sich von der Adresse des physischen Speicherorts im Cache, in dem die Zieladresse gespeichert ist. Das Verfahren 400 erleichtert die Identifizierung der tatsächlichen physischen Adresse im Cache, wobei die vom Benutzer identifizierten Daten mit der bereitgestellten logischen Blockadresse gespeichert werden. In einer Implementierung umfasst die logische Blockadresse eine Volumen-ID und einen Offset oder entspricht dieser.
  • Die Blöcke 406 und 408 veranschaulichen ein Beispiel für die direkte Übersetzung der logischen Blockadresse in einen physischen Ort, eine physikalische Cache-Adresse, die ein Kandidat zum Speichern der Daten ist, nach denen die logische Blockadresse sucht, die Zieldaten. Die Blöcke 406 und 408 können vom Prozessor 36 gemäß den Anweisungen ausgeführt werden, die in einem Medium 60 enthalten sind, wie beispielsweise dem Befehl 68. In Block 406 wird eine Hash-Funktion auf die empfangene logische Blockadresse angewendet. In dem dargestellten Beispiel wird die Hash-Funktion auf die logische Blockadresse angewendet, die ein Volumen plus Offset umfasst, um einen Hash-Wert zu erzeugen.
  • In Block 408 Anweisungen auf dem nicht-vorübergehenden computerlesbaren Medium-Direktprozessor 36, mindestens einen Schlüssel aus dem Hash-Wert abzuleiten, wobei eine Suche in einer Hash-Tabelle unter Verwendung des mindestens einen Schlüssels durchgeführt wird, um einen Eintrag zu identifizieren, der eine Adresse enthält für einen Kandidaten für einen physischen Standort im Cache-Gerät mit niedriger Latenz für die Zieldaten. Der physische Speicherort des Kandidaten ist ein physischer Speicherort im Cache (das Cache-Gerät mit geringer Latenz, wie z. B. das in gezeigte Gerät 28), an dem sich die Zieldaten zum Zeitpunkt der letzten Suche bekanntermaßen befanden.
  • In einer Implementierung verwendet der Prozessor 36 gemäß den in dem Medium enthaltenen Anweisungen einen ersten Teil des resultierenden Hash als ersten Schlüssel für die Hash-Tabelle, um eine bestimmte Seite aus einer Vielzahl von Seiten für den Eintrag zu identifizieren. Gemäß den Anweisungen, die in dem Medium enthalten sind, verwendet der Prozessor 36 den vollständigen resultierenden Hash als zweiten Schlüssel für die Hash-Tabelle, um zu identifizieren, wo sich auf der bestimmten Seite der Eintrag befindet. In anderen Implementierungen kann ein einzelner Schlüssel, der aus dem resultierenden Hash abgeleitet ist, oder mehr als zwei Schlüssel, die aus dem resultierenden Hash abgeleitet sind, verwendet werden, um den Eintrag in der Hash-Tabelle zu lokalisieren, der die physische Kandidatenadresse oder die Cache-Adresse für die Zieldaten enthält.
  • Wie nachstehend in Bezug auf 7 beschrieben wird, wird in einigen Implementierungen eine begrenzte Anzahl von Einträgen für eine begrenzte Anzahl von entsprechenden potentiellen Blocklogikadressen beibehalten. In solchen Implementierungen werden Einträge, die logische Blockadressen (oder Schlüssel, die aus Hashes des logischen Blockadressors abgeleitet sind) mit physischen Kandidatenpositionen verknüpfen, nur für die aktivsten logischen Blockadressen oder logischen Blockadressen verwaltet. In dem Entscheidungsblock 410 weisen die Anweisungen den Prozessor 36 an, zu bestimmen, ob ein Eintrag vorhanden ist, der der logischen Blockadresse oder dem logischen Schlüssel entspricht. Mit anderen Worten wird bestimmt, ob ein Eintrag in der direkten Cache-Adressübersetzungsdatenstruktur vorhanden ist, die dem vom Hash oder Hash-Wert abgeleiteten Schlüssel zugeordnet ist. In dem oben beschriebenen Beispiel, in dem die Einträge auf verschiedenen Seiten gespeichert sind, kann eine Schlussfolgerung gezogen werden, dass ein Eintrag für die logische Blockadresse oder den logischen Schlüssel nicht vorhanden ist, wenn die Schlüssel aus dem Hash abgeleitet werden, was sich aus der Anwendung des Hash ergibt Funktion zur logischen Blockadresse, entsprechen keinen Seiten in der direkten Cache-Datenlokalisierungsdatenstruktur.
  • Unter Umständen, in denen die direkte Cache-Adressübersetzungsdatenstruktur einen Eintrag enthält, der dem aus dem Hash abgeleiteten Schlüssel entspricht, weisen die Anweisungen den Prozessor 36 an, dann die Gültigkeit des Eintrags zu überprüfen, um zu überprüfen, ob die Adresse für den physischen Standort des Kandidaten für das Ziel bestimmt ist Die im Eintrag gefundenen Daten enthalten tatsächlich die Zieldaten. Zusätzlich zu der Adresse für den physischen Standort des Kandidaten für die Zieldaten enthält der in Block 408 gefundene Eintrag eine zweite Datenkennung (DI-2). Die zweite Datenkennung identifiziert die Daten, die der logischen Blockadresse entsprechen, die Zieldaten. In dem dargestellten Beispiel kann der Eintrag, der die Adresse für den physischen Standort des Kandidaten enthält, auch andere Informationen enthalten, wie beispielsweise die Länge der Daten, die am physischen Standort des Kandidaten gespeichert sind. Jeder Eintrag, der einer anderen logischen Blockadresse zugeordnet ist, kann eine entsprechende erste Datenkennung haben.
  • Wenn Daten in den Cache geschrieben werden, wird den Daten eine erste Datenkennung D1-1 zugewiesen. Die zweite Datenkennung, die manchmal als Blockeinheit (BU) bezeichnet wird, wird den Daten selbst zugewiesen, unabhängig von dem physischen Ort, an dem die Daten gegenwärtig gespeichert sind. Die erste Datenkennung D1-1 und die zweite Datenkennung D1-2 erleichtern die Bestimmung, ob der physische Standort des Kandidaten, dessen Adresse im Eintrag gefunden wird, tatsächlich die Zieldaten enthält.
  • Wie durch die Blöcke 412 und 414 angezeigt, weisen die Anweisungen den Prozessor 36 an, die erste Datenkennung zu lesen, die an dem physischen Kandidatenort gespeichert ist, entsprechend den tatsächlichen Daten, die an dem physischen Kandidatenort gespeichert sind, und die erste Datenkennung mit der zweiten Datenkennung zu vergleichen (DI-2) im Eintrag. Wie durch Block 416 angegeben, kommt der Prozess 36 zu dem Schluss, dass die an dem identifizierten physischen Kandidatenort gespeicherten Daten schließen, wenn die erste vom physischen Standort des Kandidaten gelesene Datenkennung gleich der zweiten im Eintrag gespeicherten Datenkennung ist (Teil der Datenstruktur des direkten Cache-Standorts) Durch die Adresse in dem Eintrag, die der logischen Blockadresse entspricht, werden die gleichen Daten von der logischen Blockadresse erfasst. Infolgedessen weisen die Anweisungen den Prozessor 36 an, auf die Zieldaten am physischen Standort des Kandidaten zuzugreifen. Wie oben beschrieben, kann ein solcher Zugriff das Ändern der vorhandenen Daten am physischen Standort des Kandidaten oder das Lesen der Daten am physischen Standort des Kandidaten beinhalten, wenn ein solches Lesen die Daten nicht ändert.
  • Wie durch Block 418 angegeben, kommt der Prozessor 36 als Antwort darauf, dass die erste vom physischen Standort des Kandidaten gelesene Datenkennung nicht mit der zweiten Datenkennung übereinstimmt, die in dem Eintrag gespeichert ist, der die Adresse des physischen Standortes des Kandidaten enthält, zu dem Schluss, dass die Zieldaten-Nr länger am physischen Standort des Kandidaten wohnt; Die Daten am physischen Standort des Kandidaten sind nicht die Zieldaten, die der logischen Blockadresse entsprechen. Infolgedessen weisen die Anweisungen den Prozessor 36 an, die physikalische Kandidatenadresse in dem Eintrag von der logischen Blockadresse (logische Blockadresse) für die Zieldaten zu trennen. In dem dargestellten Beispiel beinhaltet eine solche Trennung das vollständige Entfernen des Eintrags, der der logischen Blockadresse oder dem logischen Schlüssel entspricht.
  • Wie durch die Blöcke 420 und 422 angegeben, als Reaktion auf das Fehlen eines Eintrags in der direkten Cache-Datenlokalisierungsstruktur (im Beispiel die Hash-Tabelle), der der logischen Blockadresse oder dem Schlüssel entspricht, oder als Antwort auf den vorhandenen Eintrag, der jedoch eine enthält Adresse 400 für einen physischen Standort eines Kandidaten, der die Zieldaten nicht enthält (D1-1 ist nicht gleich D1-2). Das Verfahren 400 verwendet automatisch den mehrstufigen Übersetzungsindex, um zu versuchen, den physischen Standort im Cache für die Zieldaten zu lokalisieren . Die Blöcke 420 und 422 veranschaulichen ein Beispiel für die Übersetzung der logischen Blockadresse in einen erwarteten physischen Ort oder eine Cache-Adresse für die Zieldaten unter Verwendung eines mehrstufigen Übersetzungsindex. Wie durch Block 420 angegeben, weisen die Anweisungen den Prozessor 36 an, die logische Blockadresse in eine logische Cache-Adresse zu übersetzen. Wie durch Block 422 angegeben, weisen die Anweisungen nach dem Abrufen oder Identifizieren der logischen Cache-Adresse den Prozessor 36 an, die logische Cache-Adresse in einen erwarteten physischen Ort (physischen Cache-Ort oder Adresse) für die Zieldaten zu übersetzen.
  • Der „erwartete“ physische Standort ist eine Adresse, die vom mehrstufigen Übersetzungsindex für den physischen Standort bereitgestellt wird, von dem erwartet wird, dass er die Zieldaten enthält. Obwohl nicht notwendigerweise garantiert werden kann, dass sich die Zieldaten am erwarteten physischen Ort oder an der Adresse des erwarteten physischen Ortes befinden, der durch die mehrstufige Übersetzung der Blöcke 420 und 422 bereitgestellt wird, kann der erwartete physische Ort maßgeblicher sein als der bereitgestellte physische Ort des Kandidaten durch die direkte Cache-Standortdatenstruktur und Ausgabe in den Blöcken 406 und 408. Wie oben beschrieben, ist der erwartete physische Standort maßgeblicher als der mögliche physische Standort des Kandidaten, da der erwartete physische Standort derzeit wahrscheinlich die Zieldaten enthält, da der zur Ausführung der Blöcke 420 und 422 verwendete mehrstufige Übersetzungsindex im Anschluss häufiger aktualisiert wird Verschieben von Daten innerhalb des Cache, beispielsweise als Ergebnis der oben beschriebenen Speicherbereinigungsprozesse. Im Gegensatz dazu kann in einer Implementierung die direkte Cache-Standortdatenstruktur nur als Reaktion auf einen Kandidaten für einen physischen Standortfehler (pro Block 414) oder bei Initiierung des Systems aktualisiert werden, wenn Einträge möglicherweise noch nicht vorhanden sind (pro Block 410).
  • Wie durch Block 424 angegeben, kann dann der erwartete physikalische Ort für die Zieldaten, die der logischen Blockadresse entsprechen, verwendet werden, um auf die Zieldaten zuzugreifen. Dies kann direkt erfolgen oder das Zurückkehren zu Block 408 beinhalten, wobei die direkte Cache-Standortdatenstruktur wie nachstehend beschrieben aktualisiert wurde.
  • Wie in Block 426 angegeben, wird nach der Identifizierung des erwarteten physischen Standorts für die Zieldaten in Block 422 der abgerufene erwartete physische Standort verwendet, um die Übersetzungsstruktur der direkten Cache-Adresse zu aktualisieren. Bei einer Implementierung wird die physikalische Adresse für den erwarteten physischen Standort der Zieldaten aus dem Multi - Level - Übersetzung Index abgerufen zwischengespeichert im direkten Übersetzung Datenstruktur Cache - Adresse. In dem dargestellten Beispiel, in dem ungültige Einträge für eine logische Blockadresse oder einen logischen Schlüssel (Einträge, bei denen der identifizierte D1-1 nicht gleich D1-2 ist) vollständig aus der direkten Cache-Datenlokalisierungsdatenstruktur entfernt werden (Hash-Tabelle im Beispiel), wird die Die Datenstruktur für die direkte Cache-Adressübersetzung wird aktualisiert, indem der Datenstruktur für die direkte Cache-Adressübersetzung ein brandneuer vollständiger Eintrag hinzugefügt wird, wobei der neue Eintrag die logische Blockadresse oder den logischen Schlüssel mit der Adresse des erwarteten physischen Speicherorts der Zieldaten und deren erstem verknüpft Datenkennung D1-1.
  • In anderen Implementierungen kann die Aktualisierung der direkten Cache-Adressübersetzungsstruktur auf andere Weise erfolgen. Beispielsweise können nicht aufgefüllte Einträge für Schlüssel beibehalten werden, wobei der Eintrag mit der Adresse des erwarteten physischen Speicherorts für die Zieldaten gefüllt ist, die aus dem mehrstufigen Übersetzungsindex abgerufen wurden. Anstatt den gesamten ausgefüllten Eintrag für den Schlüssel in Block 418 vollständig zu entfernen, kann der ungültige Teil des Eintrags, die Adresse für den physischen Speicherort des Kandidaten im Cache, von dem fälschlicherweise angenommen wird, dass er die Zieldaten enthält, überschrieben, entfernt und ersetzt oder auf andere Weise geändert werden alternativ die Adresse für den erwarteten physischen Ort einzuschließen, wie sie in den Blöcken 420 und 422 aus dem mehrstufigen Übersetzungsindex abgerufen wurde.
  • In dem dargestellten Beispiel spart das Verfahren 400 Speicherplatz, indem nicht notwendigerweise ein Eintrag für jede logische Blockadresse in der direkten Cache-Adressübersetzungsdatenstruktur gespeichert wird. In dem dargestellten Beispiel umfasst die direkte Cache-Adressübersetzungsdatenstruktur N-Wege-Eintragssätze, was bedeutet, dass für jede logische Blockadresse oder jeden logischen Blockschlüssel n mögliche Eintragsschlitzbereiche des verfügbaren Speicherplatzes vorhanden sind. Mit anderen Worten, einem entsprechenden Satz können mehr als N logische Blockadressen oder -schlüssel vorab zugewiesen werden, für die dem Satz zugewiesenen logischen Blockadressen oder -schlüssel sind jedoch nur N Einträge verfügbar. Wenn der Satz voll ist, sind alle vier Steckplätze mit einem Eintrag für einen entsprechenden Schlüssel belegt. Das Hinzufügen eines neuen Eintrags für einen neuen Schlüssel kann dazu führen, dass ein aktueller Eintrag für einen anderen Schlüssel aus dem Satz entfernt wird. Die Verwendung der N-Wege-Eintragssätze in der direkten Cache-Adressübersetzungsdatenstruktur bietet einen hohen Lastfaktor bei niedrigen und deterministischen Prüfkosten. In einer Implementierung verwendet die direkte Cache-Adressübersetzungsdatenstruktur 4-Wege-Eintragssätze. In anderen Implementierungen kann die direkte Cache-Adressübersetzungsdatenstruktur N-Wege-Sätze anderer Größe verwenden.
  • In dem dargestellten Beispiel verwaltet das Verfahren 400 die Einträge in jedem Satz in einer Reihenfolge der zuletzt verwendeten (LRU), indem neue und aufgerufene Einträge nach oben (zuletzt verwendetes Ende (MRU)) befördert und der untere Eintrag (LRU) entfernt werden, wenn a Ein neuer Eintrag wird in einen vollständigen Satz eingefügt. Infolgedessen verwendet das Verfahren 400 eine Position in der Menge als Indikator für eine „Temperatur“ des Eintrags, dh wie aktiv der Eintrag ist. Infolgedessen kann die Größe der Datenstruktur für die direkte Cache-Adressübersetzung mit geringem Speicherplatzaufwand reguliert werden. Wie in Block 426 angegeben, wird ein neuer Eintrag, der die Adresse für den erwarteten physischen Standort enthält, am oberen Ende (MRU-Ende) seines vorgegebenen Satzes platziert. In ähnlicher Weise befindet sich, wie durch Block 428 angegeben, der Eintrag, der die Adresse für den physischen Standort des Kandidaten enthält, oben, wenn ein vorhandener Eintrag validiert wurde und auf die Zieldaten an dem physischen Kandidatenort zugegriffen wurde, der durch die Adresse in dem Eintrag identifiziert wurde (MRU-Ende) des vorgesehenen Satzes. Unter Umständen, in denen sich der Eintrag bereits am oberen Rand des festgelegten Satzes befindet, wird keine Aktion ausgeführt. In Fällen, in denen sich der Eintrag nicht oben befindet, wird der Eintrag an den oberen Rand des festgelegten Satzes von Einträgen verschoben oder verschoben. In anderen Implementierungen können andere Schemata verwendet werden, um vorhandene Einträge in den N-Wege-Sätzen der direkten Cache-Adressübersetzungsdatenstruktur zu entfernen, wenn ein neuer Eintrag zu einem vollständigen Satz hinzugefügt werden soll.
  • 7 ist ein Diagramm, das eine beispielhafte direkte Cache-Adressübersetzungsstruktur 540 darstellt, die als Beschleunigungsindex oder Metadaten-Bypass-Cache dient und eine Hash-Tabelle 570 verwendet. Die direkte Cache-Adressübersetzungsdatenstruktur 540 kann als Teil des Verfahrens 400 verwendet werden. In dem dargestellten Beispiel umfasst die Hash-Tabelle 570 eine zweistufige Tabelle, die ein Array von Zeigern (Vektoren 572) auf Seiten 574 (von denen einer gezeigt ist) mit einer Vielzahl von Einträgen 576 für den Schlüssel zum physischen Standort des Kandidaten (K / CPL) umfasst jede Seite. Jeder K / CPL-Eintrag kann eine Zuordnung eines Schlüssels (das Produkt einer Hash-Funktion, die auf die logische Blockadresse oder Hostadresse angewendet wird) zu einer physischen Kandidatenadresse in einem Cache umfassen, die der logischen Blockadresse oder Hostadresse entspricht. In einer Implementierung kann jede Seite 574 eine Größe von nicht mehr als 10 MB haben und wobei die Seiten mindestens 200.000 Seiten umfassen. In einer Implementierung ist jede Seite 1 MB groß, wobei die Tabelle 570 500.000 Seiten umfasst. In einer Implementierung umfasst jede Seite 574 nicht mehr als 50.000 K / CPL-Einträge 576 (Block logische Adresse zu physischen Adresseinträgen). In einer Implementierung umfasst jede Seite 32.000 K / CPL-Einträge.
  • In solchen Implementierungen kann die Größe der einzelnen Seiten 574 (nicht größer als 10 MB und in einigen Implementierungen 1 MB) von einem Speicherzuweiser effizient verwaltet werden. Wenn ein einheitlicher Allokator beispielsweise Speicher zurückfordern soll, werden Seiten möglicherweise verworfen, während nur ein kleiner Teil der Hash-Tabelle verloren geht. In solchen Implementierungen treten die meisten Zugriffe bei einer Sperre nicht in Konflikt, da eine Anzahl von Seiten 574 groß ist. Mit anderen Worten kann jede Seite 574 mit einer Sperre geschützt werden, wie beispielsweise einer Drehsperre 578, wobei jedoch die Wahrscheinlichkeit eines Sperrkonflikts für gleichzeitige Threads vernachlässigbar sein kann. Gleichzeitig ist die Anzahl der Einträge 576 auf einer Seite hoch, so dass der Speicherplatzaufwand für eine solche Sperre minimal ist. Eine solche Dimensionierung kann die Einbeziehung aller Einträge für eine große Eingabe / Ausgabe (IO) unter nur einer Sperre erreichen. Beispielsweise kann eine einzelne Sperre jede der logischen Blockadressen vor physischen Adresseinträgen der direkten Cache-Datenlokalisierungsstruktur 540 schützen, wie beispielsweise jeder der 32.000 Einträge (entsprechend 32.000 möglichen logischen Blockadressen oder den „Schlüsseln“ (resultierend aus) die Anwendung einer Hash-Funktion auf die logischen Blockadressen) in dem einen Beispiel. Infolgedessen bieten solche Implementierungen eine granulare Seitensperrung, die effizient ist und eine hohe Parallelität ermöglicht.
  • In einer Implementierung wird zum Auswählen einer geeigneten Seite 574 für einen gegebenen Schlüssel eine Hash-Funktion auf die logische Blockadresse angewendet und bestimmte Bits (z. B. die niedrigen vier Bits) des resultierenden Hash werden maskiert, und die verbleibenden Bits des Mit Hash wird die entsprechende Seite 574 für den angegebenen Schlüssel ausgewählt. Wenn Sie diese Technik verwenden, um Seitenzuordnungen für nahegelegene logische Blockadressen (z. B. logische Blockadressen (LBAs)) auszuwählen, landen diese wahrscheinlich auf derselben Seite. Innerhalb jeder Seite 574 wird ein Array von K / CPL-Paaren durch die jeweiligen Schlüssel indiziert. In einem Beispiel ist die Hash-Tabelle assoziativ in vier Richtungen gesetzt, was bedeutet, dass für jeden Schlüssel vier mögliche Slots vorhanden sind. Diese Anordnung bietet einen hohen Lastfaktor bei niedrigen und deterministischen Prüfkosten. Die Leistung wird verbessert, da alle möglichen Speicherorte für ein Element im Speicher zusammenhängend sind und in zwei CPU-Cache-Zeilen passen.
  • In einer Implementierung werden für jeden der Sätze 580-1, 580-2... 580-n (zusammen als Sätze 480 bezeichnet) einer Tabelle 570 K / CPL-Einträge in einem Satz gespeichert, basierend darauf, wie kürzlich jeder Eintrag war Zugriff (relativ zu den anderen Einträgen im Set). Als solches kann die relative Position eines K / CPL-Eintrags innerhalb eines Satzes 580 als Proxy für seine „Temperatur“ dienen (dh wie kürzlich auf den Eintrag zugegriffen wurde). In einer solchen Implementierung werden die K / CPL-Einträge in den Sätzen 580 in einer LRU-Reihenfolge verwaltet, indem neue und zugegriffene Einträge an das obere oder MRU-Ende des Satzes befördert werden und der untere oder LRU-Eintrag in dem Satz entfernt wird, wenn ein neuer Eintrag eingefügt wird in einen vollständigen Satz. Infolgedessen wird die Position im Set als Indikator für die Temperatur des Eintrags verwendet. Somit kann die LRU-Cache-Richtlinie mit geringem oder keinem Speicherplatzaufwand angenähert werden.
  • In einer Implementierung beträgt eine typische Blockgröße 4 kB. Der AK / CPL-Eintrag kann ungefähr 32 Bytes betragen. Infolgedessen beträgt das Verhältnis AI / Datenstruktur 540 zu Datengröße 32/4096, 0,7%. Beispielsweise kann ein 1,5-TB-Cache-Gerät nur 12 GB Hauptspeicher verwenden. Ohne Verwendung der Datenstruktur 540 kann ein Entwurf alternativ dieselben 12 GB verwenden, um einen Bruchteil der Daten im Cache zu speichern. Die Datenstruktur 540 erleichtert den schnellen Zugriff auf das gesamte Cache-Gerät.
  • Obwohl die Verwendung der direkten Adressübersetzungsdatenstruktur 540, wie beispielsweise einer Hash-Tabelle 570, zu Kollisionen und Räumungen führen kann, die bei einem hohen Lastfaktor nicht behandelt werden können, behebt die zusätzliche Einbeziehung des mehrstufigen Übersetzungsindex solche Bedenken. Da die direkte Adressübersetzungsdatenstruktur selbst ein Cache ist, sind Fehlschläge akzeptabel, da sie durch einen Datenübersetzungspfad durch den mehrstufigen Adressübersetzungsindex behoben werden, wenn auch mit einer etwas höheren Latenz.
  • Obwohl die vorliegende Offenbarung unter Bezugnahme auf beispielhafte Implementierungen beschrieben wurde, werden Fachleute erkennen, dass Änderungen in Form und Detail vorgenommen werden können, ohne vom Geist und Umfang des beanspruchten Gegenstands abzuweichen. Obwohl verschiedene Beispielimplementierungen so beschrieben wurden, dass sie Merkmale enthalten, die einen oder mehrere Vorteile bieten, wird beispielsweise in Betracht gezogen, dass die beschriebenen Merkmale in den beschriebenen Beispielimplementierungen oder in anderen alternativen Implementierungen miteinander ausgetauscht oder alternativ miteinander kombiniert werden können . Da die Technologie der vorliegenden Offenbarung relativ komplex ist, sind nicht alle Änderungen in der Technologie vorhersehbar. Die vorliegende Offenbarung, die unter Bezugnahme auf die beispielhaften Implementierungen beschrieben und in den folgenden Ansprüchen dargelegt ist, soll offensichtlich so weit wie möglich sein. Beispielsweise umfassen die Ansprüche, in denen ein einzelnes bestimmtes Element aufgeführt ist,, sofern nicht ausdrücklich anders angegeben, auch mehrere solcher bestimmten Elemente. Die Begriffe „erste“, „zweite“, „dritte“ usw. in den Ansprüchen unterscheiden lediglich verschiedene Elemente und sind, sofern nicht anders angegeben, nicht spezifisch mit einer bestimmten Reihenfolge oder bestimmten Nummerierung von Elementen in der Offenbarung verbunden.

Claims (20)

  1. System, das Folgendes umfasst: ein beständiges Speichergerät; ein Cache-Gerät mit geringer Latenz; ein flüchtiger Speicher; und einen Prozessor zum Ausführen von Anweisungen, die auf einem maschinenlesbaren Speichermedium gespeichert sind, um: Speichern einer direkten Cache-Adressübersetzungsdatenstruktur in dem flüchtigen Speicher, die zum direkten Übersetzen einer logischen Blockadresse für Zieldaten an einen physischen Kandidatenort auf dem Cache-Gerät verwendet werden kann; Speichern eines mehrstufigen Übersetzungsindex im flüchtigen Speicher zum Übersetzen der logischen Blockadresse für die Zieldaten in einen erwarteten physischen Ort der Zieldaten auf dem Cache-Gerät; und Bestimmen, ob sich die Zieldaten an dem physischen Kandidatenort befinden, der aus der direkten Cache-Adressübersetzungsdatenstruktur abgerufen wurde; als Antwort auf die Zieldaten, die sich am physischen Standort des Kandidaten befinden; Zugriff auf die Zieldaten; und Greifen Sie in Reaktion auf die Zieldaten, die sich nicht an der physischen Adresse des Kandidaten befinden, auf die Zieldaten an dem erwarteten physischen Ort zu, der aus dem mehrstufigen Übersetzungsindex abgerufen wurde.
  2. Speichersystem nach Anspruch 1, wobei die Cache-Vorrichtung mit niedriger Latenz eine zweite persistente Speichervorrichtung umfasst.
  3. Speichersystem nach Anspruch 2, wobei die zweite persistente Speichervorrichtung einen Speicherklassenspeicher (SCM) umfasst.
  4. Speichersystem nach Anspruch 1, wobei die direkte Cache-Adressübersetzungsdatenstruktur eine Hash-Tabelle umfasst und wobei der Prozessor, der die Anweisungen ausführt, Folgendes hat: Identifizieren eines Schlüssels basierend auf der logischen Blockadresse; Anwenden von mindestens einem Hash aus der Hash-Tabelle auf den Schlüssel, um einen gespeicherten Ort des physischen Kandidatenstandorts zu identifizieren; und Rufen Sie den physischen Standort des Kandidaten vom gespeicherten Standort ab.
  5. Speichersystem nach Anspruch 4, wobei das Anwenden des mindestens einen Hash aus der Hash-Tabelle auf den Schlüssel zum Identifizieren des gespeicherten Ortes des physischen Kandidatenortes umfasst: Anwenden eines ersten Hashs aus der Hash-Tabelle auf mindestens einen Teil des Schlüssels, um eine bestimmte Seite einer Vielzahl von Seiten zu identifizieren; und Wenden Sie den zweiten Hash aus der Hash-Tabelle auf mindestens einen Teil des Schlüssels an, um den gespeicherten Speicherort des physischen Speicherorts des Kandidaten auf der jeweiligen Seite zu identifizieren.
  6. Speichersystem nach Anspruch 5, wobei jede der mehreren Seiten durch eine Drehsperre geschützt ist.
  7. Speichersystem nach Anspruch 4, wobei die Hash-Tabelle N-Wege-assoziativ gesetzt ist, wobei N nicht größer als 6 ist.
  8. Speichersystem nach Anspruch 4, wobei die Hash-Tabelle assoziativ gesetzt ist, wobei jeder Satz in zwei Prozessor-Cache-Zeilen passt.
  9. Speichersystem nach Anspruch 4, wobei die Hash-Tabelle assoziativ gesetzt ist und wobei jeder Schlüssel einen Ort innerhalb seines entsprechenden Satzes basierend auf einer Räumungstemperatur für den Schlüssel aufweist.
  10. Speichersystem nach Anspruch 1, wobei die direkte Cache-Adressübersetzungsdatenstruktur eine erste Kennung für die Zieldaten speichert, wobei die physikalische Adresse eine zweite Kennung speichert, die den tatsächlichen Daten am physischen Kandidatenort zugewiesen ist, und wobei der Prozessor die Anweisungen ausführt besteht darin, die erste Kennung mit der zweiten Kennung zu vergleichen, um zu bestimmen, ob die tatsächlichen Daten am physischen Standort des Kandidaten die Zieldaten sind.
  11. Speichersystem nach Anspruch 1, wobei der Prozessor, der die Anweisungen ausführt und darauf reagiert, dass die erste Kennung von der zweiten Kennung verschieden ist, die direkte Cache-Adressübersetzungsdatenstruktur modifiziert, um: Trennen Sie den physischen Standort des Kandidaten von der logischen Blockadresse für die Zieldaten. Bestimmen des erwarteten physischen Standorts für die Zieldaten unter Verwendung des mehrstufigen Übersetzungsindex; und Verknüpfen Sie die tatsächlich ermittelte physische Adresse mit der logischen Blockadresse für die Zieldaten.
  12. Speichersystem nach Anspruch 1, wobei der Prozessor, der die Anweisungen ausführt und auf die logische Blockadresse für die Zieldaten reagiert, die keiner physischen Kandidatenadresse zugeordnet sind, Folgendes hat: Bestimmen des erwarteten physischen Standorts für die Zieldaten unter Verwendung des mehrstufigen Übersetzungsindex; und Ändern Sie die Datenstruktur für die direkte Cache-Adressübersetzung, um den ermittelten erwarteten physischen Standort mit der logischen Blockadresse für die Zieldaten zu verknüpfen.
  13. Speichersystem nach Anspruch 1, wobei der mehrstufige Übersetzungsindex umfasst: eine erste Ebene, die die logische Blockadresse für die Zieldaten in eine Kennung für die Zieldaten übersetzt; und eine zweite Ebene, die die Kennung in den erwarteten physischen Ort der Zieldaten übersetzt.
  14. Speichersystem nach Anspruch 1, wobei der mehrstufige Übersetzungsindex umfasst: eine erste Indextabelle, die die logische Blockadresse in eine erste interne Kennung übersetzt; und eine zweite Indextabelle, die die erste interne Kennung in den physischen Ort auf dem Cache-Gerät übersetzt, wobei der Prozessor die erste interne Kennung einem zweiten physischen Ort als Antwort auf Daten am physischen Ort zuordnet, die an den zweiten physischen Ort verschoben werden.
  15. Verfahren, das Folgendes umfasst: Speichern einer direkten Cache-Adressübersetzungsdatenstruktur in einem flüchtigen Speicher, der eine logische Blockadresse für Zieldaten direkt an einen physischen Kandidatenort auf einem Cache-Gerät übersetzt; Speichern eines mehrstufigen Übersetzungsindex in dem flüchtigen Speicher, der zum Übersetzen der logischen Blockadresse für die Zieldaten an einen erwarteten physischen Ort auf dem Cache-Gerät verwendet werden kann; Bestimmen, ob sich die Zieldaten an dem physischen Kandidatenort befinden, der aus der direkten Cache-Adressübersetzungsdatenstruktur abgerufen wurde; und In Reaktion auf die Zieldaten, die sich nicht am physischen Standort des Kandidaten befinden, wird auf die Zieldaten am erwarteten physischen Standort zugegriffen, die aus dem mehrstufigen Übersetzungsindex abgerufen wurden, und der abgerufene erwartete physische Standort wird in der direkten Cache-Adressübersetzungsstruktur zwischengespeichert.
  16. Verfahren nach Anspruch 14, wobei die direkte Cache-Adressübersetzungsdatenstruktur eine Hash-Tabelle umfasst, wobei das Verfahren ferner umfasst: Identifizieren eines Schlüssels basierend auf der logischen Blockadresse; Anwenden von mindestens einem Hash aus der Hash-Tabelle auf den Schlüssel, um einen gespeicherten Ort des physischen Kandidatenstandorts zu identifizieren; und Abrufen des physischen Standortes des Kandidaten vom gespeicherten Standort.
  17. Verfahren nach Anspruch 14, wobei die direkte Cache-Adressübersetzungsdatenstruktur eine erste Kennung für die Zieldaten speichert, wobei die physikalische Adresse eine zweite Kennung speichert, die den tatsächlichen Daten an dem physischen Kandidatenort zugewiesen ist, wobei das Verfahren ferner das Vergleichen der ersten Kennung umfasst an die zweite Kennung, um zu bestimmen, ob die tatsächlichen Daten am physischen Standort des Kandidaten die Zieldaten sind.
  18. Verfahren nach Anspruch 15, wobei in Reaktion darauf, dass der erste Bezeichner von dem zweiten Bezeichner verschieden ist, die direkte Cache-Adressübersetzungsdatenstruktur modifiziert wird, um: Trennen Sie die physische Adresse des Kandidaten von der logischen Blockadresse für die Zieldaten. Bestimmen des erwarteten physischen Standorts für die Zieldaten unter Verwendung des mehrstufigen Übersetzungsindex; und Verknüpfen Sie die tatsächlich ermittelte physische Adresse mit der logischen Blockadresse für die Zieldaten.
  19. Verfahren nach Anspruch 14, wobei als Antwort auf die logische Blockadresse für die Zieldaten kein physikalischer Kandidatenort in der direkten Cache-Adressübersetzungsdatenstruktur zugeordnet ist: Bestimmen des erwarteten physischen Standorts für die Zieldaten unter Verwendung des mehrstufigen Übersetzungsindex; und Ändern der direkten Cache-Adressübersetzungsdatenstruktur, um die bestimmte tatsächliche physikalische Adresse mit der logischen Blockadresse für die Zieldaten zu verknüpfen.
  20. Ein nicht vorübergehendes computerlesbares Medium, das Anweisungen enthält, um einen Prozessor an folgende Adresse zu leiten: eine logische Blockadresse für Zieldaten erhalten; die empfangene logische Blockadresse direkt in einen physischen Speicherort des Kandidaten-Cache übersetzen; Bestimmen, ob sich die Zieldaten am physischen Speicherort des Kandidaten-Cache befinden; als Reaktion auf die Zieldaten, die sich am physischen Speicherort des Kandidatencaches befinden, greifen Sie auf die Zieldaten am physischen Speicherort des Kandidatencaches zu; als Antwort auf die Zieldaten, die sich nicht am physischen Speicherort des Kandidaten-Cache befinden: die logische Blockadresse in eine logische Cache-Adresse übersetzen; die logische Cache-Adresse in eine erwartete physikalische Adresse übersetzen; und Zugriff auf die Zieldaten unter der erwarteten physischen Adresse.
DE102020104701.0A 2019-04-26 2020-02-21 Cache data location system Granted DE102020104701A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/396,555 2019-04-26
US16/396,555 US11226904B2 (en) 2019-04-26 2019-04-26 Cache data location system

Publications (1)

Publication Number Publication Date
DE102020104701A1 true DE102020104701A1 (de) 2020-10-29

Family

ID=72839942

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020104701.0A Granted DE102020104701A1 (de) 2019-04-26 2020-02-21 Cache data location system

Country Status (3)

Country Link
US (1) US11226904B2 (de)
CN (1) CN111858404B (de)
DE (1) DE102020104701A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10977189B2 (en) * 2019-09-06 2021-04-13 Seagate Technology Llc Reducing forward mapping table size using hashing
US11461299B2 (en) 2020-06-30 2022-10-04 Hewlett Packard Enterprise Development Lp Key-value index with node buffers
US11556513B2 (en) 2020-06-30 2023-01-17 Hewlett Packard Enterprise Development Lp Generating snapshots of a key-value index
US11461240B2 (en) 2020-10-01 2022-10-04 Hewlett Packard Enterprise Development Lp Metadata cache for storing manifest portion
US11593328B2 (en) 2020-10-07 2023-02-28 Hewlett Packard Enterprise Development Lp Update of deduplication fingerprint index in a cache memory
US11379367B2 (en) * 2020-11-19 2022-07-05 Micron Technology, Inc. Enhancement for activation and deactivation of memory address regions
CN113849455B (zh) * 2021-09-28 2023-09-29 致真存储(北京)科技有限公司 一种基于混合式存储器的mcu及缓存数据的方法

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7886126B2 (en) * 2005-01-14 2011-02-08 Intel Corporation Extended paging tables to map guest physical memory addresses from virtual memory page tables to host physical memory addresses in a virtual machine system
GB2471715A (en) 2009-07-10 2011-01-12 Hewlett Packard Development Co Determining the data chunks to be used as seed data to restore a database, from manifests of chunks stored in a de-duplicated data chunk store.
US8386745B2 (en) * 2009-07-24 2013-02-26 Advanced Micro Devices, Inc. I/O memory management unit including multilevel address translation for I/O and computation offload
US8453257B2 (en) 2009-08-14 2013-05-28 International Business Machines Corporation Approach for securing distributed deduplication software
US8392661B1 (en) * 2009-09-21 2013-03-05 Tilera Corporation Managing cache coherence
US9003159B2 (en) * 2009-10-05 2015-04-07 Marvell World Trade Ltd. Data caching in non-volatile memory
US8832154B1 (en) * 2009-12-08 2014-09-09 Netapp, Inc. Object location service for network-based content repository
US8285918B2 (en) 2009-12-11 2012-10-09 Nimble Storage, Inc. Flash memory cache for data storage device
US20110283048A1 (en) * 2010-05-11 2011-11-17 Seagate Technology Llc Structured mapping system for a memory device
US8627026B2 (en) 2011-08-19 2014-01-07 Hitachi, Ltd. Storage apparatus and additional data writing method
US9684601B2 (en) * 2012-05-10 2017-06-20 Arm Limited Data processing apparatus having cache and translation lookaside buffer
CA2877284A1 (en) 2012-06-18 2013-12-27 Actifio, Inc. Enhanced data management virtualization system
US9268682B2 (en) * 2012-10-05 2016-02-23 Skyera, Llc Methods, devices and systems for physical-to-logical mapping in solid state drives
US9514054B2 (en) 2014-07-08 2016-12-06 Netapp, Inc. Method to persistent invalidation to ensure cache durability
US9852076B1 (en) 2014-12-18 2017-12-26 Violin Systems Llc Caching of metadata for deduplicated LUNs
US9916241B2 (en) 2015-08-14 2018-03-13 Netapp, Inc. Storage controller caching using symmetric storage class memory devices
CN105404596B (zh) 2015-10-30 2018-07-20 华为技术有限公司 一种数据传输方法、装置及系统
US10402394B2 (en) 2016-11-03 2019-09-03 Veritas Technologies Llc Systems and methods for flushing data in a virtual computing environment
US9990281B1 (en) * 2016-11-29 2018-06-05 Sap Se Multi-level memory mapping
CN107193758A (zh) 2017-05-19 2017-09-22 记忆科技(深圳)有限公司 一种固态硬盘的映射表管理方法及固态硬盘
US10372687B1 (en) 2017-08-03 2019-08-06 EMC IP Holding Company LLC Speeding de-duplication using a temporal digest cache
US10402094B2 (en) * 2017-10-17 2019-09-03 Seagate Technology Llc Mapping system for data storage devices
US11093454B2 (en) 2017-10-31 2021-08-17 EMC IP Holding Company LLC Speeding deduplication using a most wanted digest cache
US10319445B1 (en) * 2017-11-30 2019-06-11 Western Digital Technologies, Inc. Programming unprogrammed upper page during lower page programming of multi-level storage cells
JP6995723B2 (ja) * 2018-09-19 2022-01-17 キオクシア株式会社 メモリシステム、ストレージシステム、および制御方法
US10776276B2 (en) 2018-11-30 2020-09-15 Hewlett Packard Enterprise Development Lp Bypass storage class memory read cache based on a queue depth threshold
US10732881B1 (en) 2019-01-30 2020-08-04 Hewlett Packard Enterprise Development Lp Region cloning for deduplication
US11030107B2 (en) 2019-04-19 2021-06-08 Hewlett Packard Enterprise Development Lp Storage class memory queue depth threshold adjustment
US20210034584A1 (en) 2019-08-02 2021-02-04 EMC IP Holding Company LLC Inline deduplication using stream detection

Also Published As

Publication number Publication date
US20200341909A1 (en) 2020-10-29
US11226904B2 (en) 2022-01-18
CN111858404B (zh) 2022-12-27
CN111858404A (zh) 2020-10-30

Similar Documents

Publication Publication Date Title
DE102020104701A1 (de) Cache data location system
DE102017128952B4 (de) Datenspeichervorrichtung, die konfiguriert ist, um eine nicht-blockierende Steuerungs-Aktualisierungsoperation auszuführen
DE102019132371A1 (de) Zuordnungsverwaltung logisch zu physisch unter Verwendung von nichtflüchtigem Speicher
DE60035151T2 (de) Hardware-Anordnung zur Verwaltung von Cachespeicherstrukturen in einem Datenspeichersystem
DE112014006118B4 (de) Spekulatives Vorab-Holen von in einem Flash-Speicher gespeicherten Daten
DE60320026T2 (de) Verbessertes speichermanagement für echtzeit-anwendungen
DE112013001284B4 (de) Adaptive Cachespeicher-Umstufungen in einem Caching-System mit zwei Stufen
DE102014014076A1 (de) Reduzierte Adressenkonvertierung mit mehreren Seitengrößen
DE69738101T2 (de) Verwaltung des Zugangs zu Objekten mit Hilfe von Referenzen mit drei Zuständen
DE60222402T2 (de) Verfahren und system zur spekulativen ungültigkeitserklärung von zeilen in einem cachespeicher
DE69629140T2 (de) Cachefähigkeitsattribut für virtuelle Adressen in Cachespeichern mit sowohl virtuellen als auch physikalischem Index
DE112017002941T5 (de) Arbeitslastoptimierte Datendeduplizierung mittels Phantomfingerabdrücken
DE102019105879A1 (de) Verwaltung von kohärenten Verknüpfungen und Mehr-Ebenen-Speicher
DE112013002938B4 (de) Übersetzen der Basistabelle von Speichern
DE102013200032B4 (de) Herabstufen von partiellen Speicherspuren aus einem ersten Cachespeicher in einen zweiten Cachespeicher
DE19961499A1 (de) Caching von Objekten in Platten-gestützten Datenbanken
DE112019000629B4 (de) Koordination von cacheoperationen
DE202010017666U1 (de) Partitionsverteilung bei einer Datenspeichervorrichtung mit Flash-Speicherchips
DE112012002615T5 (de) Vorabladen von Datenspuren und Paritätsdaten zur Verwendung zum Auslagern aktualisierter Spuren
DE2241257A1 (de) Datenverarbeitende anlage
DE102009031125A1 (de) Nand-Fehlerbehandlung
DE102020122182A1 (de) Virtuelle-maschine-replikation und -migration
DE602004007925T2 (de) Verwalten einer beziehung zwischen einem zielvolumen und einem quellenvolumen
DE10219623A1 (de) System und Verfahren zur Speicherentscheidung unter Verwendung von mehreren Warteschlangen
DE112018002032T5 (de) Gemeinsames nutzen von virtuellen und realen übersetzungen in einem virtuellen cache

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: PROCK, THOMAS, DR., GB

R012 Request for examination validly filed
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TEX., US

R016 Response to examination communication
R018 Grant decision by examination section/examining division