DE102015005817B4 - System und Verfahren zum Cachen von SSD Speichergerät- Leseanforderungsergebnissen - Google Patents

System und Verfahren zum Cachen von SSD Speichergerät- Leseanforderungsergebnissen Download PDF

Info

Publication number
DE102015005817B4
DE102015005817B4 DE102015005817.7A DE102015005817A DE102015005817B4 DE 102015005817 B4 DE102015005817 B4 DE 102015005817B4 DE 102015005817 A DE102015005817 A DE 102015005817A DE 102015005817 B4 DE102015005817 B4 DE 102015005817B4
Authority
DE
Germany
Prior art keywords
data
read request
responsive
host device
storage device
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.)
Active
Application number
DE102015005817.7A
Other languages
English (en)
Other versions
DE102015005817A1 (de
Inventor
Lee Anton Sendelbach
Jeffrey S. Werning
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.)
Western Digital Technologies Inc
Original Assignee
Western Digital Technologies Inc
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 Western Digital Technologies Inc filed Critical Western Digital Technologies Inc
Publication of DE102015005817A1 publication Critical patent/DE102015005817A1/de
Application granted granted Critical
Publication of DE102015005817B4 publication Critical patent/DE102015005817B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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
    • 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/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
    • 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/122—Replacement control using replacement algorithms of the least frequently used [LFU] type, e.g. with individual count value
    • 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
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4204—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus
    • G06F13/4221—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being an input/output bus, e.g. ISA bus, EISA bus, PCI bus, SCSI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0613—Improving I/O performance in relation to throughput
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0656—Data buffering arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0688—Non-volatile semiconductor memory arrays
    • 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/604—Details relating to cache allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device

Abstract

Verfahren (300,400) zum Cachen von Leseanforderungsergebnissen eines SSD Speichergerätes (110,116,122), das Folgendes umfasst:Empfangen (304) einer ersten Leseanforderung an einem SSD Speichergerät (110,116,122) von einem kommunikativ an das SSD Speichergerät gekoppelten Host-Gerät (102);Abrufen (306) eines ersten komprimierten Datenchunks aus dem SSD Speichergerät in Ansprechen auf die erste Leseanforderung unter Nutzung eines Controllers des SSD Speichergerätes;Dekomprimieren (308) des ersten komprimierten Datenchunks, um einen ersten dekomprimierten Datenchunk zu erzeugen, wobei der erste dekomprimierte Datenchunk Folgendes umfasst:einen oder mehrere erste dekomprimierte Datenblöcke, die auf die erste Leseanforderung ansprechen; undeinen oder mehrere erste dekomprimierte Datenblöcke, die nicht auf die erste Leseanforderung ansprechen;Zurückgeben (310) des einen oder der mehreren ersten dekomprimierten Datenblöcke,die auf die erste Leseanforderung ansprechen, an das Host-Gerät;Cachen eines oder mehrerer zusätzlicher Blöcke des ersten dekomprimierten Datenchunks in einem Datenpuffer (138) für spätere Leseanforderungen, wobei der eine oder die mehreren zusätzlichen Blöcke den einen oder die mehreren dekomprimierten Datenblöcke umfassen, die nicht auf die erste Leseanforderung ansprechen;Empfangen (416) einer zweiten Leseanforderung an einem SSD Speichergerät von dem Host-Gerät;Bestimmen (418), dass die Daten für die zweite Leseanforderung im Datenpuffer sind; undZurückgeben (426) einer Scatter/Gather-Liste, die auf die zweite Leseanforderung anspricht, an das Host-Gerät.

Description

  • Allgemeiner Stand der Technik
  • In einem Adapter eines Festkörpergeräts (Solid State Device, SSD), der Datenkomprimierungen vornimmt, können etliche logikblockadressierte Blöcke (LBAs) zusammengepackt werden, um eine viel größere Einheit (z. B. einen Datenchunk) zu bilden. Diese Einheit kann dann eine Komprimierungsengine im Adapter durchlaufen, die bewirken kann, dass die komprimierten LBA-Blöcke viel weniger Platz einnehmen, als wenn sie in ihrer eigentlichen Größe gespeichert würden. Dieser komprimierte Datenchunk wird dann im SSD (z. B. in einem Flashspeicherelement vom NAND-Typ) gespeichert. Dabei lässt sich die Größe um mindestens 50% reduzieren. Dies bedeutet, dass etliche LBA-Blöcke als einzelne Einheit in einem Flashspeicherelement gespeichert werden können. Wenn auf diese LBA-Blöcke zum Lesen zugegriffen wird, muss der komprimierte Datenchunk aus dem Flashspeicherelement abgerufen und dann dekomprimiert werden. Von allen dekomprimierten LBA-Blöcken wird potenziell nur ein einziger LBA-Block benötigt, um die Leseanforderung zu erfüllen.
  • Peripheral Component Interconnect Express (PCIe) wird häufig genutzt, um SSDs mit einem Host-System zu verbinden. Die PCI-Express-Systemarchitektur ist mit Leistungseinschränkungen behaftet. Zunächst haben typische PCI-Express-Fabrics mit einer großen Geräteausgangsfächerung (etwa eine Unternehmensspeicherbackplane) eine Upstream-Gesamtbandbreite (von einem PCI-Express-Switch, der dem Host vorgeschaltet ist), die geringer ist als eine Downstream-Bandbreite (von demselben PCI-Express-Switch, der allen verbundenen Speichercontrollern nachgeschaltet ist). Dies führt möglicherweise zu einem Engpass an einem PCIe-Switch, falls die Bandbreite nachgeschalteter Einrichtungen größer ist als die Upstream-Bandbreite. Ein solcher Engpass kann das Abrufen von Leseergebnissen aus einem SSD in ein Host-Gerät verzögern.
  • US 2013/024 645 A1 beschreibt das Abfangen einer angeforderten Speicheroperation, die einem konventionellen Speicher entspricht. Die angeforderte Speicheroperation wird übersetzt, um auf einen strukturierten Speicher angewendet zu werden.
  • US 2011/099 351 A1 beschreibt eine Technik zum Routing von Daten für eine verbesserte Deduplizierung in einem Speicherserver-Cluster beinhaltend das Berechnen eines Wertes, der für jeden Knoten im Cluster zusammengenommen die auf dem Knoten gespeicherten Daten darstellt, wie beispielsweise ein „geometrisches Zentrum“ des Knotens. Neue oder geänderte Daten werden an den Knoten weitergeleitet, der Daten gespeichert hat, die mit den neuen oder geänderten Daten identisch oder am ähnlichsten sind, wie sie aufgrund dieser Werte bestimmt wurden. Jeder Knoten speichert eine Vielzahl von Datenblöcken, wobei jeder Block mehrere Deduplizierungssegmente beinhaltet. Für jedes Deduplizierungssegment in jedem Knoten wird ein Inhaltshash berechnet, und für jeden Chunk wird ein Ähnlichkeitshash aus den Inhaltshashes aller Segmente im Chunk berechnet. Ein geometrisches Zentrum eines Knotens wird aus den Ähnlichkeitshashes der im Knoten gespeicherten Chunks berechnet.
  • Weiterhin wird „Gather-scatter (vector addressing)“ beschrieben unter Wikipedia: https://en.wikipedia.org/wiki/Gather-scatter_(vector_addressing) - 4 May 2013.
  • Kurze Darstellung der Offenbarung
  • Es werden Techniken zum Cachen von Ergebnissen einer Leseanforderung in einem Festkörpergerät offenbart. In einigen Ausführungsformen sind die Techniken umsetzbar als Verfahren zum Cachen von Leseanforderungsergebnissen eines SSD Speichergerätes gemäß Anspruch 1.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels kann der Datenchunk durch eine Logikblockadresse angezeigt werden.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels kann der Datenpuffer in einem Speicherelement des Festkörpergeräts bereitgestellt sein.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels kann der Datenpuffer in einem Peripheral-Component-Interconnect-Express(PCIe)-assoziierten Speicherelement des Host-Geräts bereitgestellt sein.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels können die Techniken Empfangen einer zweiten Datenanforderung vom Host-Gerät, Bestimmen, dass auf die zweite Datenanforderung ansprechende Daten im Datenpuffer enthalten sind, und Bedienen der zweiten Datenanforderung vom Host-Gerät unter Nutzung von im Datenpuffer enthaltenen Daten beinhalten.
  • Gemäß weiteren Aspekten dieses Ausführungsbeispiels kann das Bedienen der zweiten Datenanforderung vom Host-Gerät unter Nutzung von im Datenpuffer enthaltenen Daten Bereitstellen eines Scatter-Gather-Listeneintrags für das Host-Gerät, der auf ein Speicherelement im die ansprechenden Daten enthaltenden Datenpuffer verweist, beinhalten.
  • Gemäß weiteren Aspekten dieses Ausführungsbeispiels kann das Bestimmen, dass auf die zweite Datenanforderung ansprechende Daten im Datenpuffer enthalten sind, durch einen Treiber im Host-Gerät durchgeführt werden.
  • Gemäß weiteren Aspekten dieses Ausführungsbeispiels kann das Bestimmen, dass auf die zweite Datenanforderung ansprechende Daten im Datenpuffer enthalten sind, durch das Festkörpergerät durchgeführt werden.
  • Gemäß weiteren Aspekten dieses Ausführungsbeispiels kann die Scatter-Gather-Liste von einem Treiber im Host-Gerät bereitgestellt werden.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels können die Techniken weiter Aufzeichnen eines oder mehrerer Schreibvorgänge an Daten im Festkörpergerät und Bestimmen basierend auf der einen oder den mehreren aufgezeichneten Schreibanforderungen, ob Daten im Datenpuffer gültig sind, beinhalten.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels können die Techniken weiter Empfangen einer zweiten Datenanforderung vom Host-Gerät, Bestimmen, dass auf die zweite Datenanforderung ansprechende Daten im Datenpuffer enthalten sind, und Bestimmen basierend auf einer oder mehreren aufgezeichneten Schreibanforderungen, dass Daten im Datenpuffer nicht gültig sind, beinhalten. Basierend auf der Bestimmung, dass diese gültigen ansprechenden Daten nicht im Puffer sind, können die Techniken Abrufen eines zweiten komprimierten Datenchunks aus dem Festkörpergerät unter Nutzung des Controllers des Festkörpergeräts, Dekomprimieren des zweiten komprimierten Datenchunks und Zurückgeben eines Blocks des zweiten Datenchunks, der auf die zweite Datenanforderung anspricht, an das Host-Gerät beinhalten.
  • Gemäß weiteren Aspekten dieses Ausführungsbeispiels können die Techniken Nutzen eines Algorithmus zum Aufrechterhalten des Datenpuffers beinhalten.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels kann der Algorithmus einen Least-Recently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer und/oder einen Least-Frequently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer und/oder einen Adaptive-Replacement-Cache-Algorithmus zum Auslagern von Daten aus dem Datenpuffer beinhalten.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels kann das Host-Gerät Folgendes beinhalten: einen Unternehmensserver und/oder einen Datenbankserver und/oder eine Workstation und/oder einen Computer.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels kann das Festkörpergerät ein Peripheral-Component-Interconnect-Express(PCIe)-Gerät beinhalten. Obgleich es als Festkörpergerät beschrieben wird, können Ausführungsformen auch Geräte beinhalten, die möglicherweise keine Festkörpergeräte sind (z. B. PCIe-Festplattenlaufwerke).
  • In einigen Ausführungsformen sind die Techniken zum Cachen von Leseanforderungsergebnissen eines SSD Speichergerätes umsetzbar als Computerprogrammprodukt gemäß Anspruch 15.
  • In einigen Ausführungsformen sind die Techniken zum Cachen von Festkörpergerät-Leseanforderungsergebnissen umsetzbar als System zum Cachen von Leseanforderungsergebnissen eines SSD Speichergerätes gemäß Anspruch 16.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels kann der Datenpuffer in einem Speicherelement des Festkörpergeräts bereitgestellt sein.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels kann der Datenpuffer in einem Peripheral-Component-Interconnect-Express(PCIe)-assoziierten Speicherelement des Host-Geräts bereitgestellt sein.
  • Gemäß zusätzlichen Aspekten dieses Ausführungsbeispiels beinhalten die Techniken möglicherweise weiter einen Befehl zum Bestimmen an einem Treiber im Host-Gerät, dass auf eine zweite Datenanforderung ansprechende Daten im Datenpuffer enthalten sind, und einen Befehl zum Bedienen der zweiten Datenanforderung vom Host-Gerät unter Nutzung von im Datenpuffer enthaltenen Daten, wobei das Bedienen der zweiten Datenanforderung vom Host-Gerät unter Nutzung von im Datenpuffer enthaltenen Daten Bereitstellen eines Scatter-Gather-Listeneintrags für das Host-Gerät, der auf ein Speicherelement im die ansprechenden Daten enthaltenden Datenpuffer verweist, umfasst.
  • Figurenliste
  • Um ein umfassenderes Verständnis der vorliegenden Offenbarung zu vermitteln, wird nun Bezug auf die beiliegenden Zeichnungen genommen, in denen gleiche Elemente mit gleichen Bezugszeichen versehen sind. Diese Zeichnungen sind nicht derart auszulegen, dass sie die vorliegende Offenbarung einschränken, sondern sollen rein beispielhaft sein.
    • 1 zeigt ein beispielhaftes Blockschema, das eine Vielzahl von Festkörpergeräten in Kommunikation mit einem Host-Gerät veranschaulicht, gemäß einer Ausführungsform der vorliegenden Offenbarung.
    • 2 veranschaulicht ein beispielhaftes Modul zum Cachen von Festkörpergerät-Leseanforderungsergebnissen gemäß einer Ausführungsform der vorliegenden Offenbarung.
    • 3 veranschaulicht ein Ablaufdiagramm, welches das Cachen von Festkörpergerät-Leseanforderungsergebnissen abbildet, gemäß einer Ausführungsform der vorliegenden Offenbarung.
    • 4 veranschaulicht ein Ablaufdiagramm, welches das Cachen von Festkörpergerät-Leseanforderungsergebnissen abbildet, gemäß einer Ausführungsform der vorliegenden Offenbarung.
  • Beschreibung
  • Die vorliegende Offenbarung betrifft das Cachen von Festkörpergerät-Leseanforderungsergebnissen. Ausführungsformen der vorliegenden Offenbarung stellen Systeme und Verfahren bereit, über die Blöcke, die in Ansprechen auf eine Leseanforderung abgerufen werden, jedoch nicht nötig sind, um eine Leseanforderung zu erfüllen, gecacht werden können. In einem Adapter eines Festkörpergeräts (Solid State Device, SSD), der Datenkomprimierungen vornimmt, können etliche logikblockadressierte Blöcke (LBAs) zusammengepackt werden, um eine viel größere Einheit zu bilden. Diese Einheit kann dann eine Komprimierungsengine im Adapter durchlaufen, die bewirken kann, dass die komprimierten LBA-Blöcke viel weniger Platz einnehmen, als wenn sie in ihrer eigentlichen Größe gespeichert würden. Dieser komprimierte Datenchunk wird dann im SSD (z. B. in einem Flashspeicherelement vom NAND-Typ) gespeichert. Dabei lässt sich die Größe um mindestens 50% reduzieren. Dies bedeutet, dass etliche LBA-Blöcke als einzelne Einheit in einem Flashspeicherelement gespeichert werden können. Wenn auf diese LBA-Blöcke zum Lesen zugegriffen wird, muss der komprimierte Datenchunk aus dem Flashspeicherelement abgerufen und dann dekomprimiert werden. Von allen dekomprimierten LBA-Blöcken wird potenziell nur ein einziger LBA-Block benötigt, um die Leseanforderung zu erfüllen. Systeme verwerfen herkömmlich die dekomprimierten Blöcke, die nicht nötig sind, um eine Leseanforderung zu erfüllen. Ausführungsformen der vorliegenden Offenbarung stellen Systeme und Verfahren zum Cachen solcher extra vorhandenen Blöcke bereit. In einigen Ausführungsformen lässt sich ein solches Cachen in einem SSD-Gerät durchführen. In einer oder mehreren Ausführungsformen lässt sich ein solches Cachen in einem Host-Gerät durchführen (z. B. in Ausführungsformen, die auf einer Non-Volatile-Memory-express(NVMe)-Spezifikation basieren). Durch Cachen, sei es auf einem Host oder in einem SSD, kann die Leistung bei sequenziellen Lesevorgängen verbessert werden. Durch Cachen unter Nutzung des Speicherelements eines Hosts kann Platz in einem PCIe-Adapter zum Speichern von Blöcken für künftige Zugriffe freigemacht werden. Durch Cachen in einem mit einem Host assoziierten Speicherelement lässt sich auch das große Speicherelement im Host nutzen, um Lesevorgänge spekulativ zu speichern. Dadurch kann für spekulative Lesevorgänge schneller auf einen Host zugegriffen und die Leistung eines PCIe-basierten SSD-Adapters verbessert werden.
  • Unter jetziger Bezugnahme auf die Zeichnungen ist 1 ein beispielhaftes Blockschema, das ein Festkörpergerät in Kommunikation mit einem Host-Gerät veranschaulicht, gemäß einer Ausführungsform der vorliegenden Offenbarung. 1 beinhaltet eine Anzahl von Computertechnologien wie ein Host-System 102, eine Host-CPU 104 und einen PCI-Express-Stammkomplex 106, der einen Treiber 150 enthält. Der PCI-Express-Switch 108 kann eine Vielzahl von Zielen (z. B. Festkörpergeräte wie NVMe-basierte Ziele) wie die Ziele 110, 116 und 122 über den PCI-Express-Stammkomplex 106 kommunikativ an das Host-System 102 koppeln.
  • Das Ziel 110 kann einen NVMe-Controller 112 und einen nicht flüchtigen Speicher 114 enthalten. Das Ziel 116 kann einen NVMe-Controller 118 und einen nicht flüchtigen Speicher 120 enthalten. Das Ziel 122 kann einen NVMe-Controller 124 und einen nicht flüchtigen Speicher 126 enthalten.
  • Ein Systemspeicherelement 128 kann speicherelementbasierte Einrichtungen enthalten, die für das Host-System 102 über eine Speicherschnittstelle (z.B. ein Double Data Rate Type Three Synchronous Dynamic Random Access Memory (DDR3 SDRAM)) zugänglich sind. Das Systemspeicherelement 128 kann in irgendeiner geeigneten Weise ausgebildet sein, etwa unterem anderem als Festkörperspeicher (z. B. Flashspeicher oder Festkörpergerät (SSD)), optischer Speicher und magnetischer Speicher. Wenngleich das Systemspeicherelement 128 vorzugsweise nicht flüchtig ist, kann auch ein flüchtiges Speicherelement genutzt werden. Wie in 1 abgebildet, kann das Systemspeicherelement 128 eine oder mehrere Datenstrukturen wie zum Beispiel Datenpuffer 138 enthalten.
  • Die Verbindung 142 zwischen dem PCI-Express-Stammkomplex 106 und dem PCI-Express-Switch 108 ist zum Beispiel möglicherweise eine PCI-Express-basierte Schnittstelle. Die Verbindungen 144, 146 und 148 können ebenfalls PCI-Express-basierte Schnittstellen sein. Wenngleich nur die Verbindungen 144, 146 und 148 abgebildet sind, versteht es sich, dass auch weniger oder erheblich mehr mit dem PCI-Express-Switch 108 verbundene Ziele vorhanden sein können (z. B. 96 Geräte). Wenn mehr mit dem PCI-Express-Switch 108 verbundene Ziele vorhanden sind, kann die Bandbreite an der Verbindung 142 zu einem Engpass werden.
  • Gemäß einigen Ausführungsformen können für einen oder mehrere Teile auch noch andere Schnittstellenstandards als PCIe genutzt werden, etwa unter anderem Serial Advanced Technology Attachment (SATA), Advanced Technology Attachment (ATA), Small Computer System Interface (SCSI), PCI-extended (PCI-X), Fibre Channel, Serial Attached SCSI (SAS), Secure Digital (SD), Embedded Multi-Media Card (EMMC) und Universal Flash Storage (UFS).
  • Das Host-System 102 kann in irgendeiner geeigneten Weise ausgebildet sein, etwa unter anderem als Unternehmensserver, Datenbank-Host, Workstation, Personal Computer, Mobiltelefon, Spielgerät, Personal Digital Assistant (PDA), E-Mail-/SMS-Gerät, Digitalkamera, digitales Medienabspiel(z. B. MP3)-Gerät, GPS-Navigationsgerät und TV-System.
  • Das Host-System 102 und das Zielgerät können zusätzliche Komponenten beinhalten, die in 1 nicht gezeigt sind, um die Zeichnung zu vereinfachen. Auch sind in einigen Ausführungsformen nicht alle der gezeigten Komponenten vorhanden. Weiter können die verschiedenen Controller, Blöcke und Schnittstellen in irgendeiner geeigneten Art implementiert sein. Ein Controller kann zum Beispiel als Mikroprozessor und/oder Prozessor und als computerlesbares Medium ausgebildet sein, welches computerlesbaren Programmcode (z. B. Software oder Firmware) speichert, der zum Beispiel von dem (Mikro-)Prozessor, Logikgattern, Switches, einer anwendungsspezifischen integrierten Schaltung (ASIC), einem programmierbaren Logik-Controller und einem eingebetteten Mikrocontroller ausgeführt werden kann.
  • In einem SSD-Adapter, der Datenkomprimierungen vornimmt, werden etliche LBA-Blöcke zusammengepackt, um eine viel größere Einheit zu bilden. Diese Einheit kann dann eine Komprimierungsengine in einem SSD-Adapter durchlaufen, die bewirken kann, dass LBA-Blöcke weniger Platz nutzen, als wenn sie in ihrer eigentlichen Größe gespeichert würden. Dieses Datenchunk kann dann im SSD gespeichert werden. Dabei lässt sich die Größe um mindestens 50% reduzieren. Dies bedeutet, dass etliche LBA-Blöcke als einzelne Einheit in einem SSD gespeichert werden können. Wenn auf diese LBA-Blöcke zum Lesen zugegriffen wird, muss der Datenchunk aus dem SSD abgerufen werden, und eine Dekomprimierung wird an ihm vorgenommen. Dies bedeutet, dass alle LBA-Blöcke dekomprimiert wurden, doch potenziell wird nur ein einziger LBA-Block benötigt, um die Leseanforderung zu erfüllen. Die anderen LBA-Blöcke können im SSD im RAM geführt werden, um künftige Anforderungen zu erfüllen.
  • Ausführungsformen der vorliegenden Offenbarung können die SSD-Leseleistung durch Nutzung anderer LBA-Blöcke verbessern, die während der normalen Verarbeitung einer Leseanforderung in einem kompressionsbasierten SSD abgerufen werden, jedoch nicht nötig sind, um die Leseanforderung zu erfüllen. Diese LBA-Blöcke könnten in einem SSD-Adapter, einem Host-Speicher und an einem anderen zugänglichen Ort gespeichert (z. B. gepuffert) werden.
  • In PCIe-Ausführungsformen können ein PCIe-Bus mit hoher Bandbreite und die Verfügbarkeit eines Host-Speichers die Speicherung dieser LBA-Blöcke in einem hostbasierten Speicher erleichtern. Diese spekulative Speicherung von gelesenen LBA-Blöcken in einem Host-System kann genutzt werden, um die Leistung in Szenarios mit sequenziellen oder zufälligen Lesevorgängen zu erhöhen. Wenn der Host nach diesen gecachten LBA-Blöcken fragt, kann der Adapter mit einem SGL(Scatter/Gather-Liste)-Eintrag ansprechen, der auf ein Speicherelement auf dem Hostrechner verweist.
  • Ein Treiber in einem Adapter kann zum Beispiel Befehle zum Ansehen von Leseanforderungen von einem Host enthalten. Falls eine Leseanforderung empfangen wird, kann ein Treiber bestimmen, ob ein oder mehrere zum Erfüllen der Leseanforderung nötige Blöcke in einem Puffer sind. Falls bestimmt wird, dass ein oder mehrere zum Erfüllen einer Leseanforderung nötige Blöcke in einem Puffer sind, kann ein Treiber ein Scatter/Gather-Liste(SGL)-Element bereitstellen, das auf den Speicherelementort des entsprechenden gepufferten LBA-Blocks verweist. Der Host kann den LBA-Block, so als ob das SSD per Speicherdirektzugriff (DMA) darauf zugegriffen hätte, in das Speicherelement abrufen. Daraus können Lesevorgänge mit sehr niedriger Latenz resultieren, wodurch die Leistung stark verbessert werden kann.
  • Gemäß einigen Ausführungsformen kann sich Software außerhalb eines Treibers für die Handhabung der Pufferung und Überwachung von Leseanforderungen befinden. In einer oder mehreren Ausführungsformen kann ein benutzerdefiniertes Kommando bereitgestellt werden (z. B. ein benutzerdefiniertes Lesekommando), das die Verfügbarkeit von Daten in einem Puffer vor dem Lesen von einem SSD überprüfen kann. Verfahren für Leseanforderungen, die einen Puffer in Anspruch nehmen, können in einem oder mehreren Standards (z. B. NVMe-Standards) berücksichtigt sein.
  • Gemäß einigen Ausführungsformen können Puffer durch Aufzeichnen aufrechterhalten werden. Zum Beispiel kann das Aufzeichnen in einem Adapter genutzt werden, um sicherzustellen, dass die Daten im Host gültig sind, bevor der Host zu diesen Daten umgeleitet wird. Ein Treiber kann eine oder mehrere Schreibanforderungen überwachen und aufzeichnen. Die Aufzeichnung kann verfolgen, ob die Daten, die zuvor an einen Puffer gesendet worden waren, infolge einer Schreibanforderung ungültig geworden sind. Ein Treiber kann eine Datenstruktur enthalten, die Blöcke (z. B. LBAs in einem Puffer) anzeigen kann. Falls vom Treiber eine Schreibanforderung detektiert wird, die mit einem dieser Blöcke korrespondiert, kann der Block im Puffer ungültig gemacht und/oder verworfen werden. Für spätere Leseanforderungen, die mit einem solchen Block korrespondieren, müssen der Adapter und/oder der Treiber möglicherweise erneut auf den Datenchunk zugreifen und den LBA-Block noch einmal holen.
  • In einigen Ausführungsformen können ein oder mehrere Algorithmen genutzt werden, um einen Datenpuffer aufrechtzuerhalten. Zum Beispiel nutzt ein Treiber möglicherweise einen Least-Recently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer, einen Least-Frequently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer und/oder einen Adaptive-Replacement-Cache-Algorithmus zum Auslagern von Daten aus dem Datenpuffer.
  • 2 veranschaulicht ein beispielhaftes Modul zum Cachen von Festkörpergerät-Leseanforderungsergebnissen gemäß einer Ausführungsform der vorliegenden Offenbarung. Wie in 3 abgebildet, kann ein SSD-Lesecachemodul 210 ein Blockpuffermodul 212, ein Aufzeichnungsmodul 214 und ein Pufferverwaltungsmodul 216 enthalten. In einer oder mehreren Ausführungsformen kann das SSD-Lesecachemodul 210 in einem Gerätetreiber (z. B. dem Treiber 150 von 1) oder in einem Hostbetriebssystem (z. B. der Host-CPU 104 von 1) implementiert sein. Gemäß einigen Ausführungsformen kann das SSD-Lesecachemodul 210 in einem Adapter eines SSD (z.B. Ziel 110, Ziel 116 oder Ziel 122 von 1) implementiert sein.
  • Das Blockpuffermodul 212 kann einen oder mehrere Blöcke cachen, die im Rahmen einer Leseanforderung abgerufen und dekomprimiert wurden. Komprimierte LBA-Blöcke können 50% mehr oder einen noch größeren Prozentanteil von Blöcken speichern, als wenn solche Blöcke unkomprimiert wären. Dies bedeutet, dass etliche LBA-Blöcke als einzelne Einheit in einem Flashspeicherelement gespeichert werden können. Wenn auf diese LBA-Blöcke zum Lesen zugegriffen wird, muss der komprimierte Datenchunk aus dem Flashspeicherelement abgerufen und dann dekomprimiert werden. Von allen dekomprimierten LBA-Blöcken wird potenziell nur ein einziger LBA-Block benötigt, um die Leseanforderung zu erfüllen. Das Blockcachemodul 212 kann solche extra vorhandenen Blöcke puffern. In einigen Ausführungsformen lässt sich ein solches Puffern in einem SSD-Gerät durchführen. In einer oder mehreren Ausführungsformen lässt sich ein solches Puffern in einem Host-Gerät durchführen (z. B. in Ausführungsformen, die auf einer Non-Volatile-Memory-express(NVMe)-Spezifikation basieren). Das Blockpuffermodul 212 kann Leseanforderungen von einem Host überwachen. Falls eine Leseanforderung empfangen wird, kann das Blockpuffermodul 212 bestimmen, ob ein oder mehrere zum Erfüllen der Leseanforderung nötige Blöcke in einem Puffer sind. Falls bestimmt wird, dass ein oder mehrere zum Erfüllen einer Leseanforderung nötige Blöcke in einem Puffer sind, kann das Blockpuffermodul 212 ein Scatter/Gather-Liste(SGL)-Element bereitstellen, das auf den Speicherelementort des entsprechenden gepufferten LBA-Blocks verweist. Der Host kann den LBA-Block, so als ob das SSD per Speicherdirektzugriff (DMA) darauf zugegriffen hätte, in das Speicherelement abrufen.
  • Durch Puffern durch das Blockcachemodul 212, sei es auf einem Host oder in einem SSD, lässt sich die Leistung bei sequenziellen Lesevorgängen verbessern. Durch Puffern unter Nutzung des Speicherelements eines Hosts kann Platz in einem PCIe-Adapter zum Speichern von Blöcken für künftige Zugriffe freigemacht werden. Durch Puffern in einem mit einem Host assoziierten Speicherelement kann auch das große Speicherelement im Host genutzt werden, um Lesevorgänge spekulativ zu speichern. Dadurch kann für spekulative Lesevorgänge schneller auf einen Host zugegriffen und die Leistung eines PCIe-basierten SSD-Adapters verbessert werden.
  • Das Aufzeichnungsmodul 214 kann überprüfen, ob die Daten im Host gültig sind, bevor der Host zu diesen Daten umgeleitet wird. Das Aufzeichnungsmodul 214 kann eine oder mehrere Schreibanforderungen überwachen und aufzeichnen. Das Aufzeichnungsmodul 214 kann verfolgen, ob die Daten, die zuvor an einen Puffer gesendet worden waren, infolge einer Schreibanforderung ungültig geworden sind. Das Aufzeichnungsmodul 214 kann eine Datenstruktur enthalten, die Blöcke (z. B. LBAs in einem Puffer) anzeigen kann. Falls vom Aufzeichnungsmodul 214 eine Schreibanforderung detektiert wird, die mit einem dieser Blöcke korrespondiert, kann der Block im Puffer ungültig gemacht und/oder verworfen werden. Für spätere Leseanforderungen, die mit einem solchen Block korrespondieren, kann das Aufzeichnungsmodul 214 anzeigen, dass ein Treiber möglicherweise erneut auf den entsprechenden Datenchunk zugreifen und den angeforderten LBA-Block noch einmal holen muss.
  • Das Pufferverwaltungsmodul 216 kann einen oder mehrere Algorithmen zum Aufrechterhalten eines Datenpuffers nutzen. Zum Beispiel nutzt das Pufferverwaltungsmodul 216 möglicherweise zum Beispiel einen Least-Recently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer, einen Least-Frequently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer und/oder einen Adaptive-Replacement-Cache-Algorithmus zum Auslagern von Daten aus dem Datenpuffer. Das Pufferverwaltungsmodul 216 kann einen oder mehrere Parameter akzeptieren, die eine Puffergröße, einen bevorzugten Aging-Algorithmus, einen oder mehrere Speicherelementorte zur Nutzung bei der Herstellung eines Puffers oder andere konfigurierbare Puffereinstellungen anzeigen.
  • 3 veranschaulicht ein Ablaufdiagramm, welches das Cachen von Festkörpergerät-Leseanforderungsergebnissen abbildet, gemäß einer Ausführungsform der vorliegenden Offenbarung. Der Prozess 300 ist jedoch rein beispielhaft. Der Prozess 300 kann verändert werden, z. B. indem Stufen hinzugefügt, geändert, weggelassen oder in einer anderen Reihenfolge ausgeführt werden. In der Stufe 302 kann der Prozess beginnen.
  • In der Stufe 304 kann eine Datenanforderung von einem Host empfangen werden. Zum Beispiel kann eine Leseanforderung durch einen Controller eines SSD für einen oder mehrere LBA-Blöcke empfangen werden.
  • In der Stufe 306 kann ein komprimierter Datenchunk, der eine Vielzahl von LBA-Blöcken enthält, abgerufen werden. In der Stufe 308 kann der Datenchunk dekomprimiert werden. Die Dekomprimierung kann einen oder mehrere LBA-Blöcke bereitstellen, welche die Host-Leseanforderung erfüllen. Die Dekomprimierung kann auch einen oder mehrere „extra“ vorhandene LBA-Blöcke bereitstellen, welche nicht durch die Host-Leseanforderung angefordert wurden.
  • In der Stufe 310 können ein oder mehrere auf die Host-Leseanforderung ansprechende LBA-Datenblöcke an den Host zurückgegeben werden (z. B. über eine Scatter-Gather-Liste).
  • In der Stufe 312 kann bestimmt werden, ob zusätzliche LBA-Blöcke verfügbar sind. Falls zusätzliche LBA-Blöcke verfügbar sind, können die zusätzlichen LBA-Blöcke beim Verfahren 300 in der Stufe 314 an einen Datenpuffer (z. B. im Host-Speicherelement) gesendet werden. Falls alle in Ansprechen auf eine Leseanforderung dekomprimierten Blöcke an den Host gesendet wurden (d. h. sie haben alle auf die Anforderung angesprochen), kann das Verfahren 300 in der Stufe 316 enden.
  • 4 veranschaulicht ein Ablaufdiagramm, welches das Cachen von Festkörpergerät-Leseanforderungsergebnissen abbildet, gemäß einer Ausführungsform der vorliegenden Offenbarung. Der Prozess 400 ist jedoch beispielhaft. Der Prozess 400 kann verändert werden, z. B. indem Stufen hinzugefügt, geändert, weggelassen oder in einer anderen Reihenfolge ausgeführt werden. In der Stufe 402 kann der Prozess 400 anfangen.
  • In der Stufe 404 können eine oder mehrere Schreibanforderungen aufgezeichnet werden. In einigen Ausführungsformen werden möglicherweise nur mit gepufferten Blöcken korrespondierende Schreibanforderungen aufgezeichnet.
  • Falls in einigen Ausführungsformen in der Stufe 406 Daten als überschrieben detektiert werden, können sie in der Stufe 408 aus einem Puffer entfernt werden. In einigen Ausführungsformen können sie als ungültig markiert werden. In einer oder mehreren Ausführungsformen kann ein Treiber, der eine Leseanforderung abfängt, bestimmen, dass solche gepufferten Daten ungültig sind, indem er eine Aufzeichnung liest, und kann nicht auf solche gepufferten Daten zugreifen. Die gepufferten Daten, auf die nicht zugegriffen wird, können einem Aging in einem Puffer unterliegen.
  • In der Stufe 410 kann der Puffer oder der Cache unter Nutzung eines oder mehrerer Algorithmen aufrechterhalten werden (z. B. unter Nutzung eines Least-Recently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer, eines Least-Frequently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer und/oder eines Adaptive-Replacement-Cache-Algorithmus zum Auslagern von Daten aus dem Datenpuffer). Falls in der Stufe 412 bestimmt wird, dass ein Aging von Daten in einem Puffer vorliegt, können sie aus dem Puffer entfernt werden (z. B. wenn zusätzliche Daten gepuffert werden und Platz benötigt wird).
  • In der Stufe 416 kann eine Datenanforderung von einem Host empfangen werden. Ein SSD-Treiber auf einem Host kann zum Beispiel Leseanforderungen überwachen und eine SSD-Leseanforderung vom Host empfangen.
  • In der Stufe 418 kann der Treiber bestimmen, ob die angeforderten Daten in einem Puffer sind. Falls die angeforderten Daten in einem Puffer sind, kann das Verfahren 400 in der Stufe 426 fortgeführt werden. In der Stufe 426 kann der Treiber eine Scatter-Gather-Liste (SGL) senden, die ein oder mehrere Elemente enthält, welche auf die Speicherelementorte der entsprechenden gepufferten LBA-Blöcke verweisen. Falls die Daten nicht gepuffert (oder ungültig) sind, kann das Verfahren 400 in der Stufe 420 fortgeführt werden.
  • In der Stufe 420 kann der SSD-Controller den entsprechenden SSD-Datenchunk abrufen, um die Host-Leseanforderung zu erfüllen. In der Stufe 422 kann der Datenchunk dekomprimiert werden. In der Stufe 424 kann das SSD den LBA-Datenblock senden, der auf die Host-Leseanforderung anspricht.
  • In der Stufe 428 kann der Prozess 400 enden.
  • Andere Ausführungsformen liegen auch im Schutzbereich der Erfindung und sind mit ihrem Gedanken vereinbar. Die oben beschriebene Funktionalität lässt sich zum Beispiel unter Nutzung von Software, Hardware, Firmware, Festverdrahtung oder beliebigen Kombinationen davon implementieren. Ein oder mehrere gemäß Befehlen arbeitende Computerprozessoren können die mit dem Cachen von Festkörpergerät-Leseanforderungsergebnissen assoziierten Funktionen gemäß der vorliegenden Offenbarung, wie oben beschrieben, implementieren. Falls dies der Fall ist, liegt es im Schutzbereich der vorliegenden Offenbarung, dass solche Befehle in einem oder mehreren nicht transienten prozessorlesbaren Speichermedien (z. B. auf einer Magnetspeicherplatte oder in einem anderen Speichermedium) gespeichert werden können. Darüber hinaus können sich Module, die Funktionen implementieren, physisch auch an verschiedenen Positionen befinden und unter anderem derart verteilt sein, dass Teile von Funktionen an unterschiedlichen physischen Orten implementiert sind.

Claims (19)

  1. Verfahren (300,400) zum Cachen von Leseanforderungsergebnissen eines SSD Speichergerätes (110,116,122), das Folgendes umfasst: Empfangen (304) einer ersten Leseanforderung an einem SSD Speichergerät (110,116,122) von einem kommunikativ an das SSD Speichergerät gekoppelten Host-Gerät (102); Abrufen (306) eines ersten komprimierten Datenchunks aus dem SSD Speichergerät in Ansprechen auf die erste Leseanforderung unter Nutzung eines Controllers des SSD Speichergerätes; Dekomprimieren (308) des ersten komprimierten Datenchunks, um einen ersten dekomprimierten Datenchunk zu erzeugen, wobei der erste dekomprimierte Datenchunk Folgendes umfasst: einen oder mehrere erste dekomprimierte Datenblöcke, die auf die erste Leseanforderung ansprechen; und einen oder mehrere erste dekomprimierte Datenblöcke, die nicht auf die erste Leseanforderung ansprechen; Zurückgeben (310) des einen oder der mehreren ersten dekomprimierten Datenblöcke, die auf die erste Leseanforderung ansprechen, an das Host-Gerät; Cachen eines oder mehrerer zusätzlicher Blöcke des ersten dekomprimierten Datenchunks in einem Datenpuffer (138) für spätere Leseanforderungen, wobei der eine oder die mehreren zusätzlichen Blöcke den einen oder die mehreren dekomprimierten Datenblöcke umfassen, die nicht auf die erste Leseanforderung ansprechen; Empfangen (416) einer zweiten Leseanforderung an einem SSD Speichergerät von dem Host-Gerät; Bestimmen (418), dass die Daten für die zweite Leseanforderung im Datenpuffer sind; und Zurückgeben (426) einer Scatter/Gather-Liste, die auf die zweite Leseanforderung anspricht, an das Host-Gerät.
  2. Verfahren nach Anspruch 1, wobei der erste komprimierte Datenchunk durch eine Logikblockadresse angezeigt wird.
  3. Verfahren nach Anspruch 1, wobei der Datenpuffer in einem Speicherelement des SSD Speichergerätes bereitgestellt wird.
  4. Verfahren nach Anspruch 1, wobei der Datenpuffer in einem Peripheral-Component-Interconnect-Express(PCIe)-assoziierten Speicherelement des Host-Geräts bereitgestellt wird.
  5. Verfahren nach Anspruch 1, wobei die Scatter-Gather-Liste auf ein Speicherelement im Datenpuffer verweist, der die auf die zweite Leseanforderung ansprechenden Daten enthält.
  6. Verfahren nach Anspruch 1, wobei das Bestimmen, dass auf die zweite Leseanforderung ansprechende Daten im Datenpuffer enthalten sind, durch einen Treiber im Host-Gerät durchgeführt wird.
  7. Verfahren nach Anspruch 1, wobei das Bestimmen, dass auf die zweite Leseanforderung ansprechende Daten im Datenpuffer enthalten sind, durch das SSD Speichergerät durchgeführt wird.
  8. Verfahren nach Anspruch 5, wobei die Scatter-Gather-Liste von einem Treiber im Host-Gerät bereitgestellt wird.
  9. Verfahren nach Anspruch 1, das weiter Folgendes umfasst: Aufzeichnen eines oder mehrerer Schreibvorgänge an Daten im SSD Speichergerät; und Bestimmen basierend auf der einen oder den mehreren aufgezeichneten Schreibanforderungen, ob Daten im Datenpuffer gültig sind.
  10. Verfahren nach Anspruch 9, das weiter Folgendes umfasst: Empfangen einer dritten Leseanforderung vom Host-Gerät; Bestimmen, dass auf die dritte Leseanforderung ansprechende Daten im Datenpuffer enthalten sind, Bestimmen (412) basierend auf einer oder mehreren aufgezeichneten Schreibanforderungen, dass Daten im Datenpuffer nicht gültig sind; Abrufen (420) eines zweiten komprimierten Datenchunks aus dem SSD Speichergerät unter Nutzung des Controllers des SSD Speichergerätes; Dekomprimieren (422) des zweiten komprimierten Datenchunks, um einen zweiten dekomprimierten Datenchunk zu erzeugen, wobei der zweite dekomprimierte Datenchunk einen oder mehrere zweite dekomprimierte Datenblöcke umfasst, die auf die dritte Leseanforderung ansprechen; und Zurückgeben (424) des einen oder der mehreren zweiten dekomprimierten Datenblöcke, die auf die dritte Leseanforderung ansprechen, an das Host-Gerät.
  11. Verfahren nach Anspruch 1, das weiter Nutzen (410) eines Algorithmus zum Aufrechterhalten des Datenpuffers umfasst.
  12. Verfahren nach Anspruch 11, wobei der Algorithmus zumindest einen eines Least-Recently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer, eines Least-Frequently-Used-Algorithmus zum Auslagern von Daten aus dem Datenpuffer und eines Adaptive-Replacement-Cache-Algorithmus zum Auslagern von Daten aus dem Datenpuffer umfasst.
  13. Verfahren nach Anspruch 1, wobei das Host-Gerät zumindest eines des Folgenden umfasst: einen Unternehmensserver, einen Datenbankserver, eine Workstation und einen Computer.
  14. Verfahren nach Anspruch 1, wobei das SSD Speichergerät ein Peripheral-Component-Interconnect-Express(PCIe)-Gerät umfasst.
  15. Nichttransitorisches Computerprogrammprodukt, das aus einer Reihe von in einem Computer ausführbaren Befehlen besteht, wobei das nichttransitorische Computerprogrammprodukt einen Prozess (300,400) zum Cachen von Leseanforderungsergebnissen eines SSD Speichergerätes (110,116,122) durchführt; wobei das nichttransitorische Computerprogramm folgende Schritte implementiert: Empfangen (304) einer ersten Leseanforderung an einem SSD Speichergerät (110,116,122) von einem kommunikativ an das SSD Speichergerät gekoppelten Host-Gerät (102); Abrufen (306) eines ersten komprimierten Datenchunks aus dem SSD Speichergerät in Ansprechen auf die erste Leseanforderung unter Nutzung eines Controllers des SSD Speichergerätes; Dekomprimieren (308) des ersten komprimierten Datenchunks, um einen ersten dekomprimierten Datenchunk zu erzeugen, wobei der erste dekomprimierte Datenchunk Folgendes umfasst: einen oder mehrere erste dekomprimierte Datenblöcke, die auf die erste Leseanforderung ansprechen; und einen oder mehrere erste dekomprimierte Datenblöcke, die nicht auf die erste Leseanforderung ansprechen; Zurückgeben (310) des einen oder der mehreren ersten dekomprimierten Datenblöcke, die auf die erste Leseanforderung ansprechen, an das Host-Gerät; und Cachen eines oder mehrerer zusätzlicher Blöcke des ersten dekomprimierten Datenchunks in einem Datenpuffer (138) für spätere Leseanforderungen, wobei der eine oder die mehreren zusätzlichen Blöcke den einen oder die mehreren dekomprimierten Datenblöcke umfassen, die nicht auf die erste Leseanforderung ansprechen; Empfangen (416) einer zweiten Leseanforderung an einem SSD Speichergerät von dem Host-Gerät; Bestimmen (418), dass die Daten für die zweite Leseanforderung im Datenpuffer sind; und Zurückgeben (426) einer Scatter/Gather-Liste, die auf die zweite Leseanforderung anspricht, an das Host-Gerät.
  16. System (100) zum Cachen von Leseanforderungsergebnissen eines SSD Speichergerätes, wobei das System Folgendes umfasst: ein Host-Gerät (102); ein erstes Peripheral-Component-Interconnect-Express(PCIe)-Gerät (110,116,122), das für Folgendes konfiguriert oder betreibbar ist: Senden eines oder mehrerer zusätzlicher Blöcke eines Datenchunks, der in Ansprechen auf eine erste Leseanforderung dekomprimiert wurde, an einen Datenpuffer (138), wobei der eine oder die mehreren zusätzlichen Blöcke einen oder mehrere dekomprimierten Datenblöcke umfassen, die nicht auf die erste Leseanforderung ansprechen; und einen Peripheral-Component-Interconnect-Express(PCIe)-Switch (108), der das erste PCIe-Gerät und das Host-Gerät kommunikativ koppelt, wobei das Host-Gerät für Folgendes konfiguriert oder betreibbar ist: Bestimmen (418), ob auf eine zweite Leseanforderung ansprechende Daten im Datenpuffer enthalten sind; und Bedienen (426) der zweiten Leseanforderung von im Datenpuffer enthaltenen Daten basierend auf einer Bestimmung, dass auf die zweite Leseanforderung ansprechende Daten im Datenpuffer enthalten sind; und Zurückgeben (426) einer Scatter/Gather-Liste, die auf die zweite Leseanforderung anspricht, an das Host-Gerät.
  17. System nach Anspruch 16, wobei der Datenpuffer in einem Speicherelement des ersten PCIe-Geräts bereitgestellt ist.
  18. System nach Anspruch 16, wobei der Datenpuffer in einem Peripheral-Component-Interconnect-Express(PCIe)-Speicherelement des Host-Geräts bereitgestellt ist.
  19. System nach Anspruch 16, wobei das Host-Gerät weiter für Folgendes konfiguriert oder betreibbar ist: Bestimmen an einem Treiber (150) im Host-Gerät, dass auf eine zweite Leseanforderung ansprechende Daten im Datenpuffer enthalten sind; und wobei PCIe weiter für Folgendes konfiguriert oder betreibbar ist: Bedienen der zweiten Leseanforderung vom Host-Gerät unter Nutzung von im Datenpuffer enthaltenen Daten, wobei das Bedienen der zweiten Leseanforderung vom Host-Gerät unter Nutzung von im Datenpuffer enthaltenen Daten Bereitstellen eines Scatter-Gather-Listeneintrags für das Host-Gerät, der auf ein Speicherelement im auf die zweite Leseanforderung ansprechenden Daten enthaltenden Datenpuffer verweist, umfasst.
DE102015005817.7A 2014-05-12 2015-05-06 System und Verfahren zum Cachen von SSD Speichergerät- Leseanforderungsergebnissen Active DE102015005817B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/275,468 2014-05-12
US14/275,468 US9990298B2 (en) 2014-05-12 2014-05-12 System and method for caching solid state device read request results

Publications (2)

Publication Number Publication Date
DE102015005817A1 DE102015005817A1 (de) 2015-11-12
DE102015005817B4 true DE102015005817B4 (de) 2020-10-29

Family

ID=53489071

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102015005817.7A Active DE102015005817B4 (de) 2014-05-12 2015-05-06 System und Verfahren zum Cachen von SSD Speichergerät- Leseanforderungsergebnissen

Country Status (4)

Country Link
US (1) US9990298B2 (de)
DE (1) DE102015005817B4 (de)
FR (1) FR3020885B1 (de)
GB (1) GB2528534B (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102540765B1 (ko) * 2016-09-07 2023-06-08 에스케이하이닉스 주식회사 메모리 장치 및 이를 포함하는 메모리 시스템
US10503443B2 (en) * 2016-09-13 2019-12-10 Netapp, Inc. Systems and methods for allocating data compression activities in a storage system
US10719462B2 (en) * 2018-09-25 2020-07-21 Intel Corporation Technologies for computational storage via offload kernel extensions
US11537440B2 (en) * 2019-12-19 2022-12-27 Hewlett Packard Enterprise Development Lp Infrastructure adaptive consistency level mechanism
US11360669B2 (en) * 2020-04-01 2022-06-14 Hitachi, Ltd. Storage device accelerator providing aggregation of divided plaintext data
JP7197541B2 (ja) * 2020-04-01 2022-12-27 株式会社日立製作所 ストレージ装置
CN111651396B (zh) * 2020-04-26 2021-08-10 尧云科技(西安)有限公司 一种优化的pcie完成包乱序管理电路实现方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110099351A1 (en) * 2009-10-26 2011-04-28 Netapp, Inc. Use of Similarity Hash to Route Data for Improved Deduplication in a Storage Server Cluster
US20130024645A1 (en) * 2010-05-20 2013-01-24 Hicamp Systems, Inc. Structured memory coprocessor

Family Cites Families (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481701A (en) 1991-09-13 1996-01-02 Salient Software, Inc. Method and apparatus for performing direct read of compressed data file
US5778411A (en) * 1995-05-16 1998-07-07 Symbios, Inc. Method for virtual to physical mapping in a mapped compressed virtual storage subsystem
US5946276A (en) * 1996-11-15 1999-08-31 Rimage Corporation Data flow management system for recordable media
US6105080A (en) * 1997-12-30 2000-08-15 Lsi Logic Corporation Host adapter DMA controller with automated host reply capability
US6243767B1 (en) * 1998-06-02 2001-06-05 Adaptec, Inc. System for register partitioning in multi-tasking host adapters by assigning a register set and a unique identifier in each of a plurality of hardware modules
US6889256B1 (en) * 1999-06-11 2005-05-03 Microsoft Corporation System and method for converting and reconverting between file system requests and access requests of a remote transfer protocol
US20030191876A1 (en) * 2000-02-03 2003-10-09 Fallon James J. Data storewidth accelerator
US20010047473A1 (en) * 2000-02-03 2001-11-29 Realtime Data, Llc Systems and methods for computer initialization
US6952797B1 (en) * 2000-10-25 2005-10-04 Andy Kahn Block-appended checksums
SE0004839D0 (sv) * 2000-12-22 2000-12-22 Ericsson Telefon Ab L M Method and communication apparatus in a communication system
US6754735B2 (en) * 2001-12-21 2004-06-22 Agere Systems Inc. Single descriptor scatter gather data transfer to or from a host processor
US6877059B2 (en) * 2002-03-29 2005-04-05 Emc Corporation Communications architecture for a high throughput storage processor
US6795897B2 (en) * 2002-05-15 2004-09-21 International Business Machines Corporation Selective memory controller access path for directory caching
JP4186602B2 (ja) * 2002-12-04 2008-11-26 株式会社日立製作所 ジャーナルログを利用した更新データ書込方法
US7493450B2 (en) * 2003-04-14 2009-02-17 Hewlett-Packard Development Company, L.P. Method of triggering read cache pre-fetch to increase host read throughput
DE602004004780T2 (de) * 2003-05-26 2007-12-06 Koninklijke Philips Electronics N.V. Verfahren und einrichtung zum transferieren von daten zwischen einem hauptspeicher und einer speichereinrichtung
US6954450B2 (en) * 2003-11-26 2005-10-11 Cisco Technology, Inc. Method and apparatus to provide data streaming over a network connection in a wireless MAC processor
US7522623B2 (en) * 2004-09-01 2009-04-21 Qlogic, Corporation Method and system for efficiently using buffer space
US7392340B1 (en) * 2005-03-21 2008-06-24 Western Digital Technologies, Inc. Disk drive employing stream detection engine to enhance cache management policy
US8387073B1 (en) * 2007-03-23 2013-02-26 Qlogic, Corporation Method and system for processing network packets
US7996599B2 (en) * 2007-04-25 2011-08-09 Apple Inc. Command resequencing in memory operations
US8615496B2 (en) * 2007-10-19 2013-12-24 Apple Inc. File system reliability using journaling on a storage medium
TWI375953B (en) * 2008-02-21 2012-11-01 Phison Electronics Corp Data reading method for flash memory, controller and system therof
US7966455B2 (en) * 2008-03-04 2011-06-21 International Business Machines Corporation Memory compression implementation in a multi-node server system with directly attached processor memory
US8429351B1 (en) * 2008-03-28 2013-04-23 Emc Corporation Techniques for determining an amount of data to prefetch
US8954654B2 (en) 2008-06-18 2015-02-10 Super Talent Technology, Corp. Virtual memory device (VMD) application/driver with dual-level interception for data-type splitting, meta-page grouping, and diversion of temp files to ramdisks for enhanced flash endurance
US8307044B2 (en) * 2008-08-28 2012-11-06 Netapp, Inc. Circuits, systems, and methods to integrate storage virtualization in a storage controller
US8645337B2 (en) * 2009-04-30 2014-02-04 Oracle International Corporation Storing compression units in relational tables
US9189385B2 (en) * 2010-03-22 2015-11-17 Seagate Technology Llc Scalable data structures for control and management of non-volatile storage
US20120089781A1 (en) * 2010-10-11 2012-04-12 Sandeep Ranade Mechanism for retrieving compressed data from a storage cloud
WO2012082792A2 (en) 2010-12-13 2012-06-21 Fusion-Io, Inc. Apparatus, system, and method for auto-commit memory
US9497466B2 (en) * 2011-01-17 2016-11-15 Mediatek Inc. Buffering apparatus for buffering multi-partition video/image bitstream and related method thereof
US9141527B2 (en) * 2011-02-25 2015-09-22 Intelligent Intellectual Property Holdings 2 Llc Managing cache pools
KR101720101B1 (ko) 2011-03-18 2017-03-28 삼성전자주식회사 메모리 시스템에 데이터를 쓰는 쓰기 방법 및 메모리 시스템의 데이터 쓰기 방법
US8966059B2 (en) * 2011-04-06 2015-02-24 Microsoft Technology Licensing, Llc Cached data detection
KR101833416B1 (ko) * 2011-04-27 2018-04-13 시게이트 테크놀로지 엘엘씨 데이터 리드 방법 및 이를 적용한 저장 장치
KR101438716B1 (ko) 2011-08-09 2014-09-11 엘에스아이 코포레이션 Ｉ／ｏ 디바이스 및 컴퓨팅 호스팅 상호동작
CN103392207B (zh) 2011-10-05 2017-08-04 希捷科技有限公司 非易失性存储的自身日志记录和层级一致性
US20130117744A1 (en) 2011-11-03 2013-05-09 Ocz Technology Group, Inc. Methods and apparatus for providing hypervisor-level acceleration and virtualization services
US8725939B1 (en) * 2011-11-30 2014-05-13 Emc Corporation System and method for improving cache performance
US9251086B2 (en) * 2012-01-24 2016-02-02 SanDisk Technologies, Inc. Apparatus, system, and method for managing a cache
US8687902B2 (en) * 2012-03-29 2014-04-01 Intel Corporation System, method, and computer program product for decompression of block compressed images
US9235346B2 (en) * 2012-05-04 2016-01-12 Avago Technologies General Ip (Singapore) Pte. Ltd. Dynamic map pre-fetching for improved sequential reads of a solid-state media
WO2013186828A1 (ja) 2012-06-11 2013-12-19 株式会社 日立製作所 計算機システム及び制御方法
WO2014049636A1 (en) 2012-09-25 2014-04-03 Hitachi, Ltd. Storage apparatus and method of controlling the same
US9141537B2 (en) * 2012-10-30 2015-09-22 Mangstor, Inc. Magnetic random access memory journal
US9274951B2 (en) * 2013-05-31 2016-03-01 Altera Corporation Cache memory controller for accelerated data transfer
US20150074355A1 (en) * 2013-09-12 2015-03-12 Lsi Corporation Efficient caching of file system journals
US9110786B2 (en) * 2013-11-07 2015-08-18 Sandisk Technologies Inc. Read operation prior to retrieval of scatter gather list
US20160342545A1 (en) * 2014-02-12 2016-11-24 Hitachi, Ltd. Data memory device
US9612833B2 (en) * 2014-02-28 2017-04-04 Intel Corporation Handling compressed data over distributed cache fabric

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110099351A1 (en) * 2009-10-26 2011-04-28 Netapp, Inc. Use of Similarity Hash to Route Data for Improved Deduplication in a Storage Server Cluster
US20130024645A1 (en) * 2010-05-20 2013-01-24 Hicamp Systems, Inc. Structured memory coprocessor

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
talk: Gather-scatter (vector addressing), Wikipedia, 4 May 2013, im Internet: <URL:https://en.wikipedia.org/w/index.php?title=Gather-scatter_(vector_addressing)&oldid=553468773> *

Also Published As

Publication number Publication date
US9990298B2 (en) 2018-06-05
US20150324134A1 (en) 2015-11-12
GB2528534A (en) 2016-01-27
GB2528534B (en) 2017-02-15
FR3020885B1 (fr) 2019-05-31
FR3020885A1 (de) 2015-11-13
GB201507569D0 (en) 2015-06-17
DE102015005817A1 (de) 2015-11-12

Similar Documents

Publication Publication Date Title
DE102015005817B4 (de) System und Verfahren zum Cachen von SSD Speichergerät- Leseanforderungsergebnissen
DE112017002941B4 (de) Arbeitslastoptimierte Datendeduplizierung mittels Phantomfingerabdrücken
DE112013001284B4 (de) Adaptive Cachespeicher-Umstufungen in einem Caching-System mit zwei Stufen
KR102584018B1 (ko) 압축된 데이터 백그라운드를 캐싱하는 장치, 시스템 및 방법
DE112013000900B4 (de) Bewahren von Redundanz in Datendeduplizierungssystemen unter Verwendung eines Anzeigers
DE60035151T2 (de) Hardware-Anordnung zur Verwaltung von Cachespeicherstrukturen in einem Datenspeichersystem
DE112018002951T5 (de) Verwenden eines spurformatcodes in einem cache-steuerblock für eine spur in einem cache, um lese- und schreibanforderungen in bezug auf die spur im cache zu verarbeiten
DE112016000726T5 (de) Transparente hardwareunterstützte speicherdekompression
DE102018105943A1 (de) Kontextbewusste dynamische Befehlsplanung für ein Datenspeichersystem
US9176887B2 (en) Compressed level two block buffer metadata cache
DE112012005222T5 (de) Halbleiter-Datenspeicherverwaltung
DE112012002615T5 (de) Vorabladen von Datenspuren und Paritätsdaten zur Verwendung zum Auslagern aktualisierter Spuren
DE112015003540T5 (de) Zwischenspeichertechnologien unter Einsatz von Datenkomprimierung
DE102016001591A1 (de) System und Verfahren für Copy-On-Write auf einer SSD
DE112012004540T5 (de) Selektive Speicherplatzfreigabe eines Datenspeichers unter Verwendung von Vergleichs- und Verlagerungskennzahlen
CN112204534B (zh) 分散收集列表的乱序处理方法
DE102018110012A1 (de) Speichervorrichtung, die in der Lage ist Jobs ohne Eingreifen eines Prozessors zu verwalten
DE112020000183T5 (de) Speicherungsklassenspeicherzugriff
DE112012002452T5 (de) Anpassungsfähiges Zwischenspeichern von Datensätzen für Halbleiterplatten
DE112019001863T5 (de) Verwenden von spursperren und schrittweitengruppensperren zum verwalten von cacheoperationen
DE202010018020U1 (de) Opportunistische Verbesserung einer MMIO-Anfrageabwicklung aufgrund eines Zielberichts von Raumerfordernissen
US10915478B2 (en) Method and apparatus for scatter gather processing engine in a storage controller for caching applications
EP4123463A1 (de) Beschleunigung einer speicherinternen datenbank durch datennahe verarbeitung
DE102019104871A1 (de) Nichtflüchtige dateiaktualisierungsmedien
DE102015203202B4 (de) Speicher-Subsystem mit auf ein Wrapped-Lesen folgendem kontinuierlichen Lesen

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: MEWBURN ELLIS LLP, DE

R012 Request for examination validly filed
R016 Response to examination communication
R081 Change of applicant/patentee

Owner name: WESTERN DIGITAL TECHNOLOGIES, INC. (N.D.GES.D., US

Free format text: FORMER OWNER: HGST NETHERLANDS B.V., AMSTERDAM, NL

R082 Change of representative

Representative=s name: MEWBURN ELLIS LLP, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final