DE102019106126A1

DE102019106126A1 - Massenspeicherungsvorrichtung mit vom Host eingeleiteter Pufferausräumung

Info

Publication number: DE102019106126A1
Application number: DE102019106126.1A
Authority: DE
Inventors: Romesh Trivedi; Suresh Nagarajan; Shankar Natarajan; Sriram Natarajan
Original assignee: Intel Corp
Current assignee: SK Hynix NAND Product Solutions Corp
Priority date: 2018-04-13
Filing date: 2019-03-11
Publication date: 2019-10-17
Also published as: US10877686B2; US20190042140A1; CN110377224A

Abstract

Es wird eine Vorrichtung beschrieben, die ein Halbleiterlaufwerk umfasst, das nichtflüchtigen Pufferspeicher und nichtflüchtigen Primärspeicherungsspeicher aufweist. Der nichtflüchtige Pufferspeicher soll weniger Bit pro Zelle als der nichtflüchtige Primärspeicherungsspeicher speichern. Das Halbleiterlaufwerk umfasst einen Controller zum Ausräumen des Puffers als Reaktion auf einen von einem Host empfangenen Pufferausräumbefehl. Der Controller soll bewirken, dass das Halbleiterlaufwerk Lese-/Schreibanforderungen, die neu von dem Host empfangen werden, zwischen Ausräumungen kleinerer Teile des Inhalts des Puffers, die zur Versorgung des Pufferausräumbefehls durchgeführt werden, versorgt.

Description

Technisches Gebiet
Das Gebiet der Erfindung betrifft allgemein die elektrische Ingenieurstechnik und insbesondere eine Massenspeicherungsvorrichtung mit vom Host eingeleiteter Pufferausräumung.
Stand der Technik
Mit zunehmend leistungsstärker werdenden Datenverarbeitungssystemen wachsen ihre Speicherungsbedürfnisse weiter. Massenspeicherungsvorrichtungen, die mit minimaler Latenz auf Lese-/Schreibanforderungen reagieren können, während Stromverbrauchswerte in vernünftigen Grenzen gehalten werden, sind folglich sehr erwünscht. Hohe Leistungsfähigkeit und niedriger Stromverbrauch sind leider schwierig zu erzielen, weil die Entwurfsverbesserungen, die zu schnellerem Betrieb führen, wie etwa Cache-artiger Puffer, auch zu wenig oder keiner Zeit führen, um die Vorrichtung in einen energiesparenden Sleep-Modus zu versetzen (weil der Puffer während Vorrichtungsleerlaufzeit in tiefere Massenspeicherung ausgeräumt wird).
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung lässt sich aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen erhalten. Es zeigen:

1 ein Halbleiterlaufwerk;
2a und 2b einen Vergleich des Stands der Technik mit verbesserten Ausräumeigenschaften;
3 Logs, die durch SSD geführt werden können, die hostseitig eingeleitete Ausräumbefehle unterstützen;
4 einen Prozess zum Reagieren auf einen hostseitig eingeleiteten Ausräumbefehl;
5 einen Prozess zum Reagieren auf einen hostseitig eingeleiteten Ausräum - Abbruchbefehl;
6 eine beispielhafte SSD-Identitäts-Datenstruktur;
7 ein beispielhaftes Datenverarbeitungssystem.

Ausführliche Beschreibung
Wie in der Technik bekannt ist, speichern verschiedene Flash-Speichertechnologien verschiedene Anzahlen von Bit pro Zelle. Speziell speichert eine Einzelpegelzelle (SLC) ein Bit pro Zelle, eine Mehrpegelzelle (MLC) speichert zwei Bit pro Zelle, eine Ternärpegelzelle (TLC) speichert drei Bit pro Zelle und Quadpegelzelle (QLC) speichert vier Bit pro Zelle. Während eine SLC-Zelle nur zwei logische Zustände pro Zelle (eine „1“ oder eine „0“) speichern kann, erweitern die Zellentypen MLC, TLC und QLC, die als verschiedene Arten von „Mehrbit“ -Speicherungszellen charakterisiert werden können, die Speicherungskapazität einer Flash-Vorrichtung sehr, weil mehr als zwei digitale Zustände in einer einzigen Zelle gespeichert werden können (z.B. können in einer MLC-Zelle vier digitale Zustände gespeichert werden, in einer TLC-Zelle können acht digitale Zustände gespeichert werden und in einer QLC-Zelle können 16 Logikzustände gespeichert werde).
Eine bestimmte Zelle, die mehr als ein Bit pro Zelle speichern kann (z.B. beliebige einer MLC-Zelle, TLC-Zelle oder QLC-Zelle) kann hierbei auch in einem SLC-Modus arbeiten. Das heißt, da diese Zellen mehr als ein Bit pro Zelle speichern können, können sie leicht zum Speichern von nur einem Bit pro Zelle verwendet werden. Jeder verschiedene logische Zustand, den eine Zelle speichern kann, wird im Allgemeinen mit einer anderen Menge von Ladung, die in der Zelle gespeichert wird, realisiert. Zum Beispiel kann eine QLC-Flash-Zelle sechzehn getrennt unterscheidbare Ladungsmengen speichern, um physisch die Möglichkeit zu realisieren, vier Bit auf einmal zu speichern. Da eine QLC-Zelle dafür ausgelegt ist, sechzehn verschiedene Ladungspegel zu speichern, kann sie ohne weiteres in einem SLC-Modus arbeiten, in dem sie nur zwei verschiedene Ladungsmengen speichert. Ähnlich können MLC- und TLC-Zellen auch in einem SLC-Modus arbeiten, in dem sie nur zwei verschiedene Ladungsmengen speichern.
Der SLC-Modus einer Mehrbitzelle weist im Allgemeinen kleinere Schreibzugriffszeiten als bei ihrem Mehrbitbetrieb auf. Wie nachfolgend ausführlicher beschrieben wird, muss hier die Schreibaktivität im SLC-Modus für Mehrbitmodus nicht so genau sein. Die kleinere Genauigkeit, die für den SLC-Modus ausreicht, führt dazu, dass verglichen mit Mehrbit-Schreiboperationen weniger Zeit notwendig ist, um digitale Informationen in die Zelle zu schreiben. Dementsprechend wurden Hybridarchitektur-Flash-SSDs implementiert, bei denen ein gewisser Teil von Mehrbit-Speicherungszellen eines SSD absichtlich in den SLC-Modus versetzt werden, um diesen Geschwindigkeitsvorteil auszunutzen.
1 zeigt ein beispielhaftes Hybrid-SSD 101. Wie in 1 zu sehen ist, ist das SSD 101 aus vielen Mehrbit-Speicherungszellen 102 zusammengesetzt (die mit mehreren Mehrbit-Flash-Halbleiterspeicherchips realisiert werden können). Die Mehrbit-Speicherungszellen 102 sind jedoch folgendermaßen aufgeteilt: 1) eine erste Partition von Zellen 103, die, obwohl ihre zugrundeliegende Technologie zu Mehrbitbetrieb fähig ist (z.B. MLC, TLC, QLC usw.), permanent oder quasi permanent in einen SLC-Betriebsmodus versetzt ist; 2) eine zweite Partition von Zellen 104, die anfänglich beim Heraufbringen des SSD im SLC-Modus arbeitet, die aber abhängig von Benutzer-Speicherungsbedürfnissen in den Mehrbit-Betrieb wechseln kann; und 3) eine dritte Partition von Zellen 105, die permanent oder quasi permanent im Mehrbitmodus arbeiten.
Die Zellen der dritten Partition 103 und die Zellen der zweiten Partition 104 werden beim Betrieb im SLC-Modus zur Implementierung eines „schnellen Cache“ oder „Puffers“ verwendet, wovon ein Benutzer des SSD 101 beobachtet, dass es verglichen mit Schreibzugriffszeiten der primären Mehrbit-Speicherungszellen 105 schnellere Schreibzugriffszeiten besitzt. Wenn hier zum Beispiel SDD 101 einen Burst von Schreibzugriffen mit effektiv zufälligen Adressen über den Burst empfängt, werden die Schreibinformationen in Zellen der ersten und/oder zweiten Partition 103, 104 geschrieben, die in einem SLC-Modus arbeiten. Hierdurch werden die Schreiboperationen schneller ausgeführt, und das Hostsystem (z.B. ein Computer, mit dem das SSD gekoppelt ist) erhält schneller Leistungsfähigkeit von dem SSD 101 als Ganzes.
Die zwei verschiedenen Partitionen 103, 104 entsprechen zwei verschiedenen Arten von SLC-Puffern: einem statischen SLC-Puffer und einem dynamischen SLC-Puffer. Spezieller entsprechen die Zellen der ersten Partition 103 einem statischen SLC-Puffer, und die Zellen der zweiten Partition 104 entsprechen einem dynamischen SLC-Puffer. Die Zellen 103 des statischen SLC-Puffers sind im Wesentlichen „Extra“-Speicherungszellen im SSD (z.B. Zellen, die die Speicherungskapazität des SSD 101 über seine angegebene Kapazität hinaus erweitern). Abhängig von der Implementierung können hier Informationen, die in die Zellen 103 des statischen SLC-Puffers geschrieben werden, danach, z.B. während eines durch den SSD-Controller 106 ausgeführten Hintergrundprozesses, in den primären Mehrbit-Speicherungsbereich 105 verlagert werden.
Im Fall des dynamischen SLC-Puffers wird, statt einen permanent partitionierten Extra-Kapazitätsbereich des SSD zu reservieren, sowie es bei den statischen SLC-Puffern geschieht, stattdessen ein SLC-Puffer mit Zellen 104 implementiert, die im SLC-Modus arbeiten können, um einen schnellen Cache-Puffer zu implementieren, oder um im Mehrbitmodus als primäre Speicherung zu arbeiten. In welchem Modus diese Zellen 104 arbeiten (SLC-Modus oder Mehrbitmodus) hängt von der Speicherungslast ab, die dem SSD 101 präsentiert wird.
Spezieller werden die Zellen 104 des dynamischen SLC-Puffers anfänglich (z.B. beim Heraufbooten der SSD-Vorrichtung) in einen SLC-Modus versetzt, während die Zellen des primären Mehrbit-Speicherungsbereichs 105 in ihren nominalen Mehrbitmodus versetzt werden. Da die angegebene maximale Speicherungskapazität die Kapazität der dynamischen Pufferzellen 104 umfasst, wenn sie sich im Mehrbitmodus befinden (und deshalb ihre maximale Kapazität von Daten halten), beginnen die Zellen 104, die dem dynamischen Puffer zugeordnet sind, zu Mehrbitbetrieb überzugehen, sobald die Speicherungslast, die dem SSD präsentiert wird, ungefähr mit der Kapazität des primären Speicherungsbereichs 105 vergleichbar ist.
Wenn diese Schwelle erreicht ist, werden jegliche zusätzliche neue Daten, die in das SSD zu schreiben sind (ohne existierende Daten zu überschreiben) im Mehrbitmodus in die Zellen 104 in dem dynamischen Puffer geschrieben, was bewirkt, dass die Größe des dynamischen SLC-Puffers schrumpft. Während die Menge an durch das SSD 101 gespeicherten Daten über und unter dieser Schwelle schwankt, gehen die Zellen 104, die dem dynamischen SLC-Puffer zugewiesen sind, zwischen dem SLC-Modus und dem Mehrbitmodus hin und her. Das heißt, wenn nach dem Überschreiten der Schwelle die Menge an gespeicherten Daten unter die Schwelle fällt, können etwaige „befreite“ dynamische SLC-Zellen (d.h. dynamische Zellen, die in den Mehrbitmodus konvertiert wurden) wieder zum SLC-Modus zurückkehren, um zuvor verlorene dynamische SLC-Puffergröße „wieder einzufangen“. Die Größe des dynamischen SLC-Puffers kann somit abhängig von der Menge an Daten, die die SSD-Vorrichtung 101 speichert, schrumpfen und expandieren.
Eine Rückschreiboperation oder „Ausräumung“ entspricht dem Schreiben von Informationen in einem statischen oder dynamischen Puffer 103, 104 zurück in den primären Mehrbit-Speicherungsbereich 105. Ausräumung kann als eine formale Festlegung („Persistenz“) von Daten an das SSD angesehen werden (obwohl die Puffer 103, 104 auch nichtflüchtig sind). Nachdem in den statischen und/oder dynamischen Puffern 103, 104 gespeicherte Daten in die primäre Mehrbitspeicherung 105 ausgeräumt wurden, können jedoch neu empfangene Schreibanforderungen, die auf andere Blöcke/Seiten von Daten als die in den Puffern 103, 104 gespeicherten abzielen, die ausgeräumt wurden, direkt über die Blöcke/Seiten von Daten in den Puffern 103, 104, die ausgeräumt wurden, geschrieben werden. Das heißt, wenn Daten in einem Puffer 103, 104 in dem primären Mehrbit-Speicherungsbereich 105 abgespeichert wurden, werden die Daten formal durch das SSD 106 persistiert und sind frei, ohne Verlust von Informationen für den Kunden in einem Puffer 103, 104 überschrieben zu werden.
Ein Problem ist jedoch die nominale Ausräumoperation sowohl des statischen als auch dynamischen Puffers 103, 104. Speziell werden als Reaktion auf Einleitung durch den SSD-Controller 106 Inhalte des statischen und dynamischen Puffers 103, 104 aktuell nur dann in den primären Mehrbit-Speicherungsbereich zurückgeschrieben, wenn das SSD 106 leerläuft. Wenn das SSD 106 stark ausgelastet ist (viele Lese-/Schreibanforderungen über einen Zeitraum empfängt), ist somit das SSD 106 fast nie im Leerlauf und es besteht wenig/keine Gelegenheit, Informationen aus den Puffern 103, 104 in den primären Mehrbit-Speicherungsbereich 105 auszuräumen.
Dementsprechend müssen Blöcke/Seiten von Daten, die sich nicht in einem Puffer 103, 104 befinden, in den langsameren primären Mehrbit-Speicherungsbereich 105 geschrieben/daraus gelesen werden. Selbst wenn das SSD 106 eine gewisse Leerlaufzeit beobachtet und Ausräumoperationen unternommen werden können, können die Ausräumoperationen selbst die gesamte Leerlaufzeit verbrauchen. Dementsprechend kann das SSD 106 niemals einen echten energiesparenden Sleep-Zustand aufweisen. Das heißt, die Gelegenheiten, zu denen ein solcher energiesparender Zustand möglich gewesen wäre, wurden in einem Modus mit höherer Leistung mit dem Schreiben der Daten der Puffer zurück in den primären Mehrbit-Speicherungsbereich 105 verbracht.
Eine Lösung besteht darin, Ausräumaktivität während des normalen aktiven Zustands des SSD 106 auf den Befehl des Hosts hin (z.B. von einer Anwendung, einem Betriebssystem (OS) und/oder Software einer virtuellen Maschine (VMM), die auf dem Host ausgeführt wird, und/oder z.B. von einer Peripheriesteuerhub-Hardware) zu verschachteln. Das heißt, der Host befiehlt dem SSD, Ausräumoperationen zwischen der Ausführung der regulär empfangenen Lese- und/oder Schreibanforderungen des SSD vom Host einzuführen.
2a und 2b vergleichen den traditionellen Ansatz mit dem verbesserten Ansatz. Hier zeigt 2a eine potenzielle Leerlaufzeit 201 zwischen zwei Zeitfenstern von aktiver Lese-/Schreibaktivität. Bemerkenswerterweise werden während der Fenster aktiver Lese-/Schreibaktivität keine Ausräumoperationen ausgeführt. Folglich müssen die Ausräumoperationen während der inaktiven Zeit 201 (als Reaktion auf einen internen SSD-Controllerbefehl) ausgeführt werden, was verhindert, dass das SSD in einen energiesparenden Zustand eintritt. Wenn im Gegensatz dazu unter Bezugnahme auf 2b Ausräumoperationen in die Fenster nominaler Verkehrsaktivität eingefügt werden, kann die Vorrichtung in der Lage sein, erweiterte Zeiträume zu beobachten, wie etwa das Fenster 202, in denen sie weder nominalen Verkehr noch Ausräumaktivität zu versorgen hat und dementsprechend in einen energiesparenden inaktiven Zustand versetzt werden kann.
Gemäß verschiedenen Ausführungsformen kann das Ausräumen der Puffer 103, 104 durch ausdrücklichen Befehl vom Host eingeleitet werden. Hier kann zum Beispiel ein Anwendungssoftwareprogramm, ein Softwareprogramm des Betriebssystems (OS) und/oder ein Softwareprogramm der Virtuellmaschinen-Überwachungsvorrichtung (VMM) und/oder Peripheriesteuerhub-Hardware, mit der das SSD gekoppelt ist, eine der primären Lasten sein, die aktuell der SSD-Vorrichtung eine signifikante Menge ihrer Lese-/Schreibaktivität sendet und/oder den Strom von Lese-/Schreibaktivität, der zum SSD gesendet wird, direkt beobachtet. Z.B. mit interner Kenntnis ihrer eigenen internen Verarbeitung kann solche Software/Hardware Momente erkennen, in denen sie nicht unbedingt unmittelbare SSD-Leistungsfähigkeit benötigt und Puffer-Ausräumbefehle an das SSD „einfließen“ lassen kann.
Das heißt, wenn allgemeiner die Hostseite ein besseres Verständnis ihrer Bedürfnisse/Anforderungen an SSD-Leistungsfähigkeit hat, kann die Hostseite opportunistisch dem SSD befehlen, seine Puffer 103, 104 auszuräumen. In günstigen Szenarien ist die Software und/oder Hardware von Hostanwendung/ OS/VMM in der Lage, genug Ausräumbefehle in einen nominalen Strom von Lese-/Schreibbefehlen einfließen zulassen, so dass erweiterte Leerlaufzeiten des SSD realisiert werden, wie etwa der Zeitraum 202 in 2b, wodurch das SSD in einen energiesparenden inaktiven Zustand versetzt werden kann. Wenn der Puffer regelmäßig ausgeräumt oder zumindest teilweise ausgeräumt wird, nimmt außerdem die Wahrscheinlichkeit ab, dass es keinen freien Pufferplatz gibt, über den eine neue Schreibanforderung überschreiben kann.
Dementsprechend ist der Host in der Lage, Schreibanforderungen mit sich kontinuierlich ändernder Block- und/oder Seitenadresse auszugeben, wobei weniger dieser Schreibanforderungen in die primäre langsamere Mehrbitspeicherung 105 gezwungen werden, weil es keinen freien Pufferplatz gibt. Vom Standpunkt des Hosts aus gesehen, vergrößert dies die Puffergröße und/oder gibt einen größeren Prozentsatz von Schreibanforderungen, die mit schnelleren SLC-Geschwindigkeiten versorgt werden. Weiterhin kann die Anwendung/das OS/die VMM z.B. intelligent Lesevorgänge grade geschriebener Seiten/Blöcke vor neuen Schreibvorgängen, die an andere Seiten/Blöcke gerichtet sind, in den Anforderungsstrom einreihen (wenn es die Datenabhängigkeit erlaubt), der zu dem SSD gesendet wird, so dass Lesevorgänge auch eine größere Chance haben, vom Puffer versorgt zu werden.
3 betrifft einen Mechanismus zum Synchronisierthalten des Hosts mit dem Pufferausräumstatus eines SSD. Der Mechanismus von 3 kann insbesondere für ein SSD geeignet sein, das mit NVMe (Non Volatile Memory Express) kompatibel ist. Wie in der Technik bekannt ist, ist NVMe eine offene logische Vorrichtungsschnittstellenspezifikation zum Zugreifen auf nichtflüchtige Speicherungsmedien, die an eine PCIe-Schnittstelle (Peripheral Component Interconnect Express) angeschlossen sind.
Die vorliegenden NVMe-Spezifikationen skizzieren eine Anzahl von Seiten, die im SDD gehalten und in die durch das SSD geschrieben wird, als „Logs“, die verschiedene betreffende Ereignisse, Beobachtungen, Status usw. des SSD über seine Laufzeit aufzeichnen. Die Seiten sind dem Host zugänglich, der die Logs begutachten kann, um den vergangenen oder aktuellen Zustand oder vergangene oder aktuelle Bedingungen des SSD zu verstehen.
Die derzeitigen NVMe-Spezifikationen skizzieren fünf solche Logs: 1) Fehlerinformationen 01h (zum Aufzeichnen von SSD-Fehlern); 2) SMART/Healthinformationen 02h (zum Aufzeichnen von Problemen/Ereignissen, wenn das SSD sich irgendwelchen von mehreren kritischen parametrischen Schwellen nähert, neben anderen betreffenden Zuständen/Beobachtungen des SSD); 3) Firmware-Slot-Information 03h; 4) Hersteller Eindeutiges SMART CAh - zum Aufzeichnen der kritischen parametrischen Schwellen, die für das SSD spezifisch sind); und 5) Befehlseffekte-Log (05h). Hier entspricht der jedem Log-Typ folgende Wert der Kennung des Logs, so wie sie in NVMe vorgesehen wird.
3 zeigt neue vorgeschlagene Logs für die NVMe-Spezifikation, in denen Ereignis-, Status- oder andere betreffende Merkmale der Ausräumaktivität/- fähigkeit des SSD durch das SSD aufgezeichnet werden. Gemäß einer Ausführungsform wird ein erstes Log 301 verwendet, um dem Host zu melden, wann irgendein vom Host eingeleitetes Ausräumen des Puffers abgeschlossen wurde (das „SLC-Puffer-Ausräumabschlusslog“, im Folgenden „Abschlusspufferlog“), und ein zweites Log 302 („vertreiberspezifisches SLC-Pufferausräumen“, im Folgenden „VS-Pufferlog“) wird verwendet, um Parameter der Puffer-Ausräumfähigkeit und den aktuellen Puffer-Ausräumstatus des SSD zu definieren. Das VS-Pufferlog 302 ermöglicht, dass verschiedene SSD-Hersteller verschiedene Pufferausräumeigenschaften haben. Eine vorgeschlagene Log-Kennung für das Abschlusspufferlog 301 ist hier F2h, und eine vorgeschlagene Log-Kennung für das VS-Pufferlog 302 ist F3h.
Auf jedes der Logs 301, 302 kann zugegriffen werden, indem der Host einen Befehl „Log-Seite holen“ an das SSD richtet, der auch die Log-Kennung für ein bestimmtes Log umfasst. Als Reaktion auf seinen Empfang des Befehls Log-Seite holen gibt das SSD das angeforderte Log (oder einen Teil davon, z.B. wenn der Host nur spezifische Byte des Log angefordert hat) zurück. Die Logs 301, 302 können in einem reservierten Bereich nichtflüchtiger Speicherressourcen des SSD (z.B. einem abpartitionierten Teil der Speicherungskapazität der Flash-Chips des SSD oder einer anderen Speicherungsressource des SSD) oder in flüchtigem Speicher, der mit dem SSD-Controller gekoppelt ist, einer gewissen Kombination von beidem usw. gehalten werden.
Das Puffer-Ausräumabschlusslog 301 verzeichnet Zeitstempel für jede abgeschlossene Puffer-Ausräumoperation, die als Reaktion auf einen vom Host eingeleiteten Puffer-Ausräumbefehl ausgeführt wird. Das heißt, wenn das SSD als Reaktion auf einen vom Host eingeleiteten Puffer-Ausräumbefehl seine statischen und dynamischen Puffer ausgeräumt hat, verzeichnet das SSD einen Zeitstempel des Abschlusses in dem Puffer-Ausräumabschlusslog 301.
Das VS-Pufferlog 302 umfasst bei verschiedenen Ausführungsformen die folgenden Parameter: 1) die maximale (volle) Größe des SLC-Puffers 311, einschließlich sowohl statischer als auch dynamischer Komponenten, wenn sie voll der Pufferung gewidmet sind; 2) verfügbare SLC-Puffergröße 312, die die aktuelle Größe des SLC-Puffers spezifiziert (deren Größe von Zeit zu Zeit aufgrund der Widmung des dynamischen Speichers für primären QLC-Betrieb abnehmen kann) spezifiziert; 3) Prozent-Abschluss des aktuellen Pufferausräumens 313, wodurch die Menge an Daten spezifiziert wird, die bei der aktuellen Ausräumoperation ausgeräumt wurde, normiert durch die Größe des Puffers, als die aktuelle Ausräumoperation eingeleitet wurde (andere Ausführungsformen können die Menge an Daten im Puffer normieren, wenn die aktuelle Ausräumoperation eingeleitet wurde); 4) ausgeräumte SLC-Pufferdaten 314 spezifiziert die Gesamtmenge an Daten, die in der aktuellen Ausräumoperation ausgeräumt wurde; 5) die Gesamtmenge von ausgeräumten Daten 315 über alle Ausräumbefehle, die zum SSD gesendet werden; 6) vergangene Zeit 316, die die Zeitdauer verzeichnet, die erforderlich ist, um die letzte voll abgeschlossene Ausräumoperation vollständig auszuräumen; 7) eine Menge von Statusbit, darunter i) ein Bit 317 zum Spezifizieren, ob der zuletzt empfangene Ausräumbefehl durch das SSD aufgehoben wurde; ii) ein Bit 318 zum Spezifizieren, ob der zuletzt empfangene Ausräumbefehl vom Host aufgehoben wurde; iii) ein Bit 319 zum Spezifizieren, dass als Reaktion darauf, dass der letzte Ausräumbefehl aufgehoben wurde, sich das SSD dabei befindet, die Ausräumoperation herunterzufahren; iv) ein Bit 320 zum Spezifizieren, wann der aktuelle Ausräumbefehl abgeschlossen wurde (was eine Zeitstempelaktualisierung des Puffer-Ausräumabschlusslog bewirkt); v) ein Bit 321 zum Spezifizieren, dass der zuletzt empfangene Ausräumbefehl aktuell ausgeführt wird (Puffer wird aktuell ausgeräumt, wurde aber noch nicht vollständig ausgeräumt); 8) Gesamtzahl der zum SSD durch den Host gesendeten Puffer-Ausräumbefehle 322; 9) Gesamtzahl der vom Host aufgehobenen Puffer-Ausräumbefehle 323; und 10) Gesamtzahl der durch den Host gesendeten Puffer-Ausräumbefehle 324, die durch das SSD aufgehoben wurden.
Wie aus den Inhalten des VS-Ausräumlog 302 ersichtlich ist, werden verschiedene Statistiken und dynamische Ereignis- oder Statusänderungen mittels des Log 302 zwischen dem SSD und dem Host übermittelt.
4 zeigt eine einfache SSD-Methodologie zum Reagieren auf einen Befehl, der durch den Host gesendet wird, um die Inhalte des Puffers auszuräumen (Puffer-Ausräumeinleitungsbefehl). Wie in 4 zu sehen ist, empfängt das SSD zunächst einen Puffer-Ausräumeinleitungsbefehl 401. Als Reaktion auf den Befehl schreibt das SSD eine Anzahl (X) von Seiten von Daten aus dem Puffer in den primären Mehrbit-Speicherungsbereich 402. Bei verschiedenen Ausführungsformen ist die Anzahl von herüberkopierten Seiten kleiner als die Anzahl von Seiten, die im Puffer gespeichert sind, und ist ein Vielfaches der Anzahl der pro Zelle in der primären Mehrbit-Speicherungsregion 105 gespeicherten Bit. Wenn zum Beispiel die primäre Mehrbit-Speicherungsregion 105 aus QLC-Technologie zusammengesetzt ist, die vier Bit pro Zelle speichert, kopiert die erste Ausräumsequenz 402 vier Seiten oder ein Vielfaches von vier Seiten herüber in den primären Mehrbit-Speicherungsbereich 105.
Hier ist wie in der Technik bekannt jedes verschiedene Bit in einer selben Mehrbitzelle gewöhnlich für eine andere Seite reserviert (z.B. L (Untere), U (Obere), X (Xtra) und T (Top) für eine QLC-Zelle). Durch Schreiben einer Anzahl von Seiten gleich der Anzahl von Bit pro Speicherungszelle in dem primären Speicherungsbereich 105 wird komplexe interne Flash-Chipsignalisierung, die zum Aktivieren irgendeiner bestimmten Zelle notwendig ist, gestrafft, um so im Idealfall die bestimmte Zelle nur einmal während einer Ausräumoperation zu aktivieren. In einer einzigen Ausräumsequenz einer Anzahl von Seiten gleich der Anzahl von Bit pro Zelle, faktorisiert durch eine bestimmte ganze Zahl, auszuräumen, erweitert diese Philosophie auf seitenweise mehr ausgeräumte Daten.
Im Einklang mit dem Ausräumen einer spezifischen Anzahl X von Seiten für die erste Iteration der Gesamt-Ausräumoperation synchronisiert sich 403 das SSD mit dem Host z.B. durch Aktualisierung entsprechender Logs. Zum Beispiel aktualisiert mit Bezug auf das VS-Pufferlog 302 das SSD die Einträge des Prozent-Abschlusses 313 und der gesamten ausgeräumten Datenmenge 314, startet den Timer 316 für die aktuelle Ausräumoperation, setzt das Bit 321, um anzugeben, dass die aktuelle Ausräumoperation abläuft, und inkrementiert die Gesamtzahl von Ausräumbefehlen 322, die durch den Host zum SSD gesendet wurden.
Das SSD synchronisiert sich auch mit dem Host mit Bezug auf andere Logs, die Aktualisierung erfordern können. Wenn zum Beispiel das SSD einen internen Fehler sieht, kann das oben erwähnte Fehlerlog aktualisiert werden, und/oder wenn sich eine kritische Schwelle des SSD nähert (z.B. Gesamtmenge geschriebener Daten, eine Maximaltemperatur, eine Maximalspannung usw.), kann das SSD das oben erwähnte SMART/Health-Log aktualisieren. Andere Synchronisierungs-„Checks“, die das SSD bei jeder Iteration des Seitenausräumens durchlaufen kann, sind 1) wenn das SSD einen bestimmten Befehl vom Host empfangen hat, der mäßige SSD-Änderung auferlegt (z.B. zum Setzen eines spezifischen Charakteristikums/Merkmals), Bestätigen des Befehls, aber Verzögern seiner Ausführung/Implementierung, bis nach Abschluss des Ausräumens; 2) wenn das SSD einen bestimmten Befehl vom Host empfangen hat, der drastische SSD-Änderung auferlegt (z.B. ein neues Firmware-Download für den SSD-Controller, ein Neuformatieren des SSD, einen Befehl zum Einleiten einer umfassenden Selbstprüfung), sendet das SSD eine Antwort zum Host, die den Befehl aufhebt.
Da sich das SSD mit dem Host 403 synchronisiert, versorgt 404 das SSD als nächstes etwaige Lese-/Schreibanforderungen, die während des Ausräumens 402 der spezifischen Anzahl von Seiten oder des Synchronisierens 403 durch das SSD empfangen wurden. Das heißt, das SSD suspendiert vorübergehend die Ausräumaktivität, so dass es tatsächlich und aktuell etwaige Leseanforderungen oder Schreibanforderungen, die z.B. seit dem Beginn der Ausräumoperation an das SSD ausgegeben wurden, verarbeiten kann. Man beachte, dass das Ausräumen nur einer spezifischen Anzahl X von Seiten während irgendeiner Iteration 402 und das Versorgen von neu empfangenen Lese-/Schreibanforderungen bei jeder Iteration 404 effektiv die Verschachtelung von Ausräumaktivität 402 mit nominalen Lese-/Schreiboperationen 404 wie oben mit Bezug auf 2b beschrieben implementiert.
Nachdem etwaige neu empfangene Lese-/Schreibanforderungen versorgt sind 404, wiederholt sich die Ausräumsequenz für eine weitere Iteration des Ausräumens einer festgesetzten Anzahl von Seiten 402, wobei mit dem Host synchronisiert 403 wird und etwaige Lese-/Schreibanforderungen, die seit der letzten Iteration empfangen wurden, verarbeitet 404 werden. Diese Zyklen werden fortgesetzt, bis der Pufferraum als ausgeräumt betrachtet wird. Bei verschiedenen Ausführungsformen muss der Puffer nicht vollständig mit Bezug auf den statischen und/oder dynamischen Puffer 103, 104 ausgeräumt werden. Das heißt, solange die ausgeräumten Pufferinhalte einem gewissen hohen Prozentsatz der Pufferinhalte entsprechen (z.B. 90%, 95% usw.), wird der Puffer als ausgeräumt betrachtet. Bei einer Ausführungsform werden Seiten aus dem dynamischen SLC-Puffer erst ausgeräumt, wenn alle Seiten im statischen SLC-Puffer ausgeräumt wurden. Bei noch weiteren Ausführungsformen wird der Puffer vollständig ausgeräumt (100% der Seiten im statischen und dynamischen Puffer 103, 104 werden in die primäre Mehrbit-Speicherung zurückgeschrieben). Dessen ungeachtet beachte man, dass die iterative Beschaffenheit des Verschachtelns von Ausräumungen und des Versorgens neuer Lese-/Schreibanforderungen mindestens bei einigen Ausführungsformen als Ausräumung von kleinen Teilen des Inhalts des Puffers (z.B. eines Seitenzählwerts gleich einem Vielfachen der Anzahl von Bit, die pro primärer Speicherungszelle gespeichert werden können) zwischen dem Versorgen neu empfangener Lese-/Schreibanforderungen charakterisiert werden kann.
Wenn der Puffer als ausgeräumt betrachtet ist, wird ein letzter Synchronisierungsprozess ausgeführt, um das VS-Pufferlog 302 und das Puffer-Ausräum-Abschlusslog 301 zu aktualisieren. Bei verschiedenen Ausführungsformen umfasst dies Setzen eines Bit 320 zur Angabe, dass das Ausräumen abgeschlossen ist, in dem VS-Pufferlog 302 und Schreiben des entsprechenden Zeitstempels in dem Puffer-Ausräumlog 301.
5 zeigt einen anderen Prozess, der durch das SSD als Reaktion darauf auszuführen ist, dass das SSD einen Befehl vom Host empfängt 501, eine aktuelle Ausräumoperation aufzuheben (Ausräum-Abbruchbefehl). Als Reaktion auf den Empfang einer solchen Anforderung schreibt das SSD weiter Daten aus dem Puffer in die Mehrbit-Speicherungsregion 105, bis das Ende eines Flash-Blocks in der Mehrbit-Speicherungsregion erreicht ist (zusätzlich wird das Host-Abbruch-Empfangen-Bit 319 des VS-Pufferlogs 302 gesetzt und der Gesamt-Host-Abbruchzähler 323 des VS-Pufferlogs 302 wird inkrementiert). Unter der Annahme, dass es mehrere Flash-Seiten pro Flash-Block gibt, sollte hier das Ende des Flash-Blocks am Ende einer Seitengrenze erreicht sein. Möglicherweise werden verglichen mit den standardmäßigen X Seiten, die während einer Ausräumiteration geschrieben 402 werden, während des Schließens des Ausräumprozesses weniger als X Seiten geschrieben. Nachdem das Ende des Flash-Blocks in der Mehrbit-Speicherungsregion 105 erreicht ist, synchronisiert sich das SSD mit dem Host durch Aktualisieren des Logs 302. Hier wird speziell Bit 318 des VS-Pufferlogs 302 gesetzt, um anzugeben, dass der Ausräumabbruch erfolgreich abgeschlossen wurde. Das Puffer-Abschlusslog 301 kann auch aktualisiert werden, um den Abschluss jedweder Menge an Ausräumaktivität widerzuspiegeln, die vor dem Herunterfahren der Ausräumoperation durchgeführt wurde.
Hier kann wieder wenn die Anwendung, das OS und/oder die VMM-Software (und/oder zugrundeliegende Hardware) die Lese-/Schreibanforderungsströme kennen, die zum Senden zum SSD vorbereitet werden oder zur Verarbeitung zu dem SSD gesendet wurden, solche Software/Hardware z.B. erkennen, dass eine Anzahl solcher neuerer/bevorstehender Lese-/Schreibvorgänge an Seiten/Blöcke gerichtet ist, die sich bereits in dem Pufferraum des SSD befinden, und deshalb etwaige aktuelle Ausräumaktivität abbrechen, weil kein freier Pufferplatz für diese neueren bevorstehenden Anforderungen benötigt wird.
Die NVMe-Spezifikation unterstützt auch Firmware-Datenstrukturen, die es einem SSD gestatten, sich und die verschiedenen Aufgaben/Funktionen (wie etwa vom Host eingeleitete Ausräumbefehle), die es ausführen kann, zu identifizieren. 6 zeigt eine vorgeschlagene Modifikation der NVMe-Spezifikation, die SSD-Identitätsdaten-Strukturinformationen definiert, um ein erstes Bit 601, das spezifiziert, ob das SSD Ausführungsformen der vom Host eingeleiteten Pufferausräumung, die oben ausführlich beschrieben wurden, unterstützt, ein zweites Bit 602, das spezifiziert (wenn das SSD vom Host eingeleitete Ausräumbefehle unterstützt), ob das SSD vom Host eingeleiteten Abbruch eines aktuellen vom Host eingeleiteten Ausräumens unterstützt, und ein drittes Bit 603, das angibt, ob das SSD Melden der Prozent-Abschluss-Informationen 313 in dem VS-Pufferlog 302 unterstützt, einzuschließen.
Wieder mit Bezug auf 1 wird die verbesserte Funktionalität des Reagierens auf vom Host eingeleitetes Pufferausräumen und dessen Implementierung wie oben ausführlich beschrieben bei verschiedenen Ausführungsformen hauptsächlich durch den Controller 106 des SSD beaufsichtigt. Der Controller 106 kann mit Logschaltkreisen, die dafür ausgelegt sind, eine bestimmte Form von Programmcode (z.B. Firmware (FW)) auszuführen (z.B. einem Mikrocontroller, einem eingebetteten Prozessor usw.), angepassten festverdrahteten Logikschaltkreisen oder programmierbaren Logikschaltkreisen (z.B. einem FPGA oder PLD) oder einer beliebigen Kombination davon implementiert werden. Soweit andere nichtflüchtige Speichertechnologien neben Flash mehr als ein Bit pro Zelle speichern können, aber langsamere Ansprechzeiten aufweisen als wenn sie Einzelbit pro Zelle Speicherung aufweisen, können die vorliegenden Lehren auch auf SSDs erweitert werden, die solche nichtflüchtigen Speichertechnologien umfassen. Solche alternative Technologien wären etwa Speichertechnologien mit Speicherungszellen, die aus Chalkogenid zusammengesetzt sind, resistive Speicher (RRAM), ferroelektrische Speicher (FeRAM), magnetische Speicher (MRAM) usw.
Als Letztes beachte man, dass die obigen Lehren auf ein SSD angewandt werden können, das nur einen statischen SLC-Puffer umfasst oder nur einen dynamischen SLC-Puffer umfasst oder einen Mehrbit-pro-Zelle-Puffer umfasst, dessen Anzahl von pro Zelle gespeicherten Bit kleiner als die Zellen des Primärspeicherungsbereichs 105 ist. Je weniger gespeicherte Bit pro Zelle, desto schneller ist die Zelle hier, so dass, obwohl obige Ausführungsformen Einzelbit pro Zelle für den Puffer betont haben, die vorliegenden Lehren Ausführungsformen, bei denen mehr als ein Bit pro Zelle im Pufferraum gespeichert wird (z.B. speichert der Pufferraum MLC, aber die Primärspeicherung ist QLC) nicht aus.
7 zeigt eine beispielhafte Abbildung eines Datenverarbeitungssystems 700 (z.B. eines Smartphone, eines Tablett-Computers, eines Laptop-Computers, eines Desktop-Computers, eines Server-Computers usw.). Wie in 7 zu sehen ist, kann das grundlegende Datenverarbeitungssystem 700 Folgendes umfassen: eine Zentralverarbeitungseinheit 701 (die z.B. mehrere Vielzweck-Verarbeitungskerne 715_1 bis 715_X umfassen kann) und einen Hauptspeichercontroller 717, angeordnet auf einem Mehrkernprozessor oder Anwendungsprozessor, Systemspeicher 702, eine Anzeige 703 (z.B. Touchscreen, Flachbildschirm), eine lokale verdrahtete Punkt-zu-Punkt-Verbindungs- (z.B. USB-) Schnittstelle 704, verschiedene Netzwerk-E/A-Funktionen 705 (wie etwa eine Ethernetschnittstelle und/oder ein Mobilfunk-Modemsubsystem), eine Schnittstelle 706 für ein drahtloses lokales Netzwerk (z.B. WiFi), eine drahtlose Punkt-zu-Punkt-Verbindungs- (z.B. Bluetooth-) Schnittstelle 707 und eine Schnittstelle 708 des Global Positioning System, verschiedene Sensoren 709_1 bis 709_Y, eine oder mehrere Kameras 710, eine Batterie 711, eine Power-Management-Steuereinheit 712, einen Lautsprecher und ein Mikrophon 713 und einen Audiocodierer/- decodierer 714.
Ein Anwendungsprozessor oder Mehrkernprozessor 750 kann einen oder mehrere Vielzweck-Verarbeitungskerne 715 in seiner CPU 701, eine oder mehrere Graphikverarbeitungseinheiten 716, eine Speicherverwaltungsfunktion 717 (z.B. einen Speichercontroller) und eine E/A-Steuerfunktion 718 umfassen. Die Vielzweck-Verarbeitungskerne 715 führen typischerweise das Betriebssystem und Anwendungssoftware des Datenverarbeitungssystems aus. Die Graphikverarbeitungseinheit 716 führt typischerweise graphikintensive Funktionen aus, z.B. um Graphikinformationen zu erzeugen, die auf der Anzeige 703 präsentiert werden. Die Speichersteuerfunktion 714 hat eine Schnittstelle mit dem Systemspeicher 702 zum Schreiben/Lesen von Daten in/von dem Systemspeicher 702. Die Power-Management-Steuereinheit 712 steuert im Allgemeinen den Stromverbrauch des Systems 700.
Die Touchscreen-Anzeige 703, die Kommunikationsschnittstellen 704-707, die GPS-Schnittstelle 708, die Sensoren 709, die Kamera(s) 710 und Lautsprecher/ Mikrophon-Codec 713, 714 können jeweils alle als verschiedene Formen von E/A (Eingabe und/oder Ausgabe) relativ zu dem Gesamtdatenverarbeitungssystem angesehen werden, einschließlich gegebenenfalls auch einer integrierten Peripherievorrichtung (z.B. der einen oder mehreren Kameras 710). Abhängig von der Implementierung können verschiedene dieser E/A-Komponenten auf dem Anwendungsprozessor/Mehrkernprozessor 750 integriert sein oder können sich außerhalb des Chips oder außerhalb der Kapselung des Anwendungsprozessors/ Mehrkernprozessors 750 befinden.
Das Datenverarbeitungssystem umfasst außerdem nichtflüchtige Speicherung 720, die die Massenspeicherungskomponente des Systems sein kann. Hier können zum Beispiel ein oder mehrere SSDs mit Fähigkeit für hostseitig eingeleitete Ausräumbefehle entweder direkt oder z.B. mittels eines Netzwerks (z.B. eines Speicherungsnetzwerks, eines lokalen Netzwerks usw.) mit dem Peripherie-Steuerhub 718 gekoppelt sein.
Ausführungsformen der Erfindung können verschiedene Prozesse wie oben dargelegt umfassen. Die Prozesse können in maschinenausführbaren Anweisungen realisiert sein. Die Anweisungen können verwendet werden, um zu bewirken, dass ein Vielzweck- oder Spezialprozessor bestimmte Prozesse ausführt. Als Alternative können diese Prozesse durch spezifische/angepasste Hardwarekomponenten ausgeführt werden, die fest verdrahtete Logikschaltkreise oder programmierbare Logikschaltkreise (z.B. FPGA, PLD) zum Ausführen der Prozesse enthalten, oder durch eine beliebige Kombination von programmierten Computerkomponenten und angepassten Hardwarekomponenten.
Elemente der vorliegenden Erfindung können auch als ein maschinenlesbares Medium zum Speichern der maschinenausführbaren Anweisungen bereitgestellt werden. Das maschinenlesbare Medium kann, aber ohne Beschränkung darauf, Disketten, optische Datenträger, CD-ROMs und magnetooptische Datenträger, Flash-Speicher, ROMs, RAMs, EPROMs, EEPROMs, magnetische oder optische Karten, Ausbreitungsmedien oder eine beliebige andere Art von Medien/ maschinenlesbarem Medium, die bzw. das zum Speichern von elektronischen Anweisungen geeignet ist, umfassen. Zum Beispiel kann die vorliegende Erfindung als ein Computerprogramm heruntergeladen werden, das mittels Datensignalen, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium über eine Kommunikationsverbindung (z.B. eine Modem- oder Netzwerkverbindung) realisiert sind, von einem entfernten Computer (z.B. einem Server) zu einem anfordernden Computer (z.B. einem Client) transferiert werden kann.
In der obigen Beschreibung wurde die Erfindung mit Bezug auf spezifische beispielhafte Ausführungsformen beschrieben. Es ist jedoch ersichtlich, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne von dem allgemeineren Wesen und Schutzumfang der Erfindung abzuweichen, der in den angefügten Ansprüchen dargelegt wird. Die Beschreibung und die Zeichnungen sind dementsprechend nicht im einschränkenden, sondern im veranschaulichenden Sinne aufzufassen.

Claims

Vorrichtung, umfassend: ein Halbleiterlaufwerk, das einen nichtflüchtigen Pufferspeicher und einen nichtflüchtigen Primärspeicherungsspeicher umfasst, wobei der nichtflüchtige Pufferspeicher weniger Bit pro Zelle als der nichtflüchtige Primärspeicherungsspeicher speichern soll, wobei das Halbleiterlaufwerk einen Controller zum Ausräumen des Puffers als Reaktion auf einen von einem Host empfangenen Pufferausräumbefehl umfasst, wobei der Controller bewirken soll, dass das Halbleiterlaufwerk Lese-/Schreibanforderungen, die neu von dem Host empfangen werden, zwischen Ausräumungen kleinerer Teile des Inhalts des Puffers, die zur Versorgung des Pufferausräumbefehls durchgeführt werden, versorgt.
Vorrichtung nach Anspruch 1, wobei der nichtflüchtige Pufferspeicher und der nichtflüchtige Primärspeicherungsspeicher aus Flash-Speicherungszellen zusammengesetzt sind.
Vorrichtung nach Anspruch 2, wobei der nichtflüchtige Pufferspeicher aus SLC-Flash-Speicherungszellen zusammengesetzt ist.
Vorrichtung nach Anspruch 3, wobei der Primärspeicherungsspeicher aus QLC-Speicherungszellen zusammengesetzt ist.
Vorrichtung nach Anspruch 1, wobei der nichtflüchtige Pufferspeicher aus einem statischen Pufferspeicher und einem dynamischen Pufferspeicher zusammengesetzt ist.
Vorrichtung nach Anspruch 5, wobei der statische Pufferspeicher und der dynamische Pufferspeicher beide aus SLC-Flash-Speicherungszellen zusammengesetzt sind.
Vorrichtung nach Anspruch 1, wobei das Halbleiterlaufwerk eine NVMe-Schnittstelle umfasst, mittels derer der Pufferausräumbefehl vom Host empfangen wird.
Vorrichtung nach Anspruch 1, wobei der Controller bewirken soll, dass das Halbleiterlaufwerk weiteres Ausräumen des Puffers als Reaktion auf einen vom Host empfangenen Ausräum-Abbruchbefehl unterlässt.
Vorrichtung nach Anspruch 1, wobei der Controller ein Log aktualisieren soll, um Abschluss des Pufferausräumbefehls anzugeben.
Vorrichtung nach Anspruch 1, wobei die kleineren Teile als eine Anzahl von Seiten gleich einem Vielfachen einer Anzahl von Bit bestimmt werden, die pro Speicherungszelle des nichtflüchtigen Primärspeicherungsspeichers gespeichert werden.
Vorrichtung, umfassend: einen Halbleiterchip mit hostseitigen Logikschaltkreisen zum Senden eines Stroms von Lese-/Schreibanforderungen zu einem Halbleiterlaufwerk und zum Einfügen eines Pufferausräumbefehls an das Halbleiterlaufwerk innerhalb des Stroms von Lese-/Schreibanforderungen.
Vorrichtung nach Anspruch 11, wobei die hostseitigen Logikschaltkreise Teil eines Peripherie-Steuerhubs sind.
Vorrichtung nach Anspruch 12, wobei die Peripheriesteuerung mittels einer NVMe-Schnittstelle mit dem Halbleiterlaufwerk kommunizieren soll.
Datenverarbeitungssystem, das den Gegenstand irgendwelcher der Ansprüche 1 bis 13 umfasst.
Vorrichtung, umfassend: Mittel zum Empfangen eines Puffer-Ausräumbefehls von einem Host; Mittel zum Empfangen von Lese-/Schreibanforderungen von dem Host; Mittel zum Ausräumen kleinerer Teile von Inhalt aus dem Puffer des Halbleiterlaufwerks zwischen jeweiligen Versorgungen der Lese-/Schreibanforderungen.