DE112018000485T5 - Komprimierer/Dekomprimierer für nicht binäre Kontextmischung - Google Patents

Abstract

Eine Technik für nicht binäre Kontextmischung in einem Komprimierer enthält ein Generieren, durch eine Mehrzahl von Kontextmodellen, von Modellvorhersagen in Bezug auf einen Wert eines nächsten Symbols, das encodiert werden soll. Eine Mischeinrichtung generiert eine Gruppe von endgültigen Vorhersagen aus den Modellvorhersagen. Ein arithmetischer Codierer generiert komprimierte Daten auf Grundlage von empfangenen Eingabesymbolen und die Gruppe von endgültigen Vorhersagen. Die empfangenen Eingabesymbole gehören zu einem Alphabet mit einer Größe von mehr als zwei, und die Mischeinrichtung generiert eine Feature-Matrix aus den Modellvorhersagen und schult einen Klassifizierer, der die Gruppe von endgültigen Vorhersagen generiert.

Description

• HINTERGRUND DER ERFINDUNG
• Diese Offenbarung betrifft Datenverarbeitung und -speicherung, und insbesondere ein Umsetzen eines Komprimierers/Dekomprimierers für nicht binäre Kontextmischung in einem Datenspeichersystem wie beispielsweise einem Flashspeichersystem.
• Ein NAND-Flashspeicher ist eine elektrisch programmierbare und löschbare nicht flüchtige Speichertechnologie, die ein oder mehrere Datenbits pro Speicherzelle als eine Ladung auf dem Floating-Gate eines Transistors oder einer ähnlichen Ladungsfallenstruktur speichert. In einer typischen Umsetzung ist ein NAND-Flashspeicher-Array in Blöcken von physischem Speicher organisiert (die auch als „Löschblöcke“ bezeichnet werden), von denen jeder mehrere physische Seiten enthält, die wiederum eine Vielzahl von Speicherzellen enthalten. Aufgrund der Anordnung der Wort- und Bit-Leitungen, die für einen Zugriff auf Speicherzellen verwendet werden, können Flashspeicher-Arrays im Allgemeinen auf Grundlage von Seiten programmiert werden, werden aber auf Blockgrundlage gelöscht.
• Wie im Stand der Technik bekannt, müssen Blöcke von NAND-Flashspeicher gelöscht werden, bevor sie mit neuen Daten programmiert werden können. Ein Block von NAND-Flashspeicherzellen wird durch Anlegen eines hohen positiven Löschspannungsimpulses an den globalen p-Wannen-Bereich des ausgewählten Blocks und durch Vorspannung gelöscht, um alle Wort-Leitungen der Speicherzellen auf Masse zu ziehen, die gelöscht werden sollen. Eine Anwendung des Löschimpulses fördert ein Tunneln von Elektronen weg von den auf Masse vorgespannten Floating-Gates der Speicherzellen, um ihnen eine positive Gesamtladung zu verleihen und somit die Spannungsschwellenwerte der Speicherzellen in den gelöschten Zustand übergehen zu lassen. Auf jeden Löschimpuls folgt im Allgemeinen eine Löschprüfungsoperation, die den Löschblock liest, um zu bestimmen, ob die Löschoperation erfolgreich war, indem zum Beispiel überprüft wird, dass weniger als eine Schwellenwertanzahl von Speicherzellen in dem Löschblock nicht erfolgreich gelöscht worden ist. Im Allgemeinen werden die Löschimpulse weiterhin an den Löschblock angelegt, bis die Löschüberprüfungsoperation erfolgreich ist oder bis eine vorbestimmte Anzahl von Löschimpulsen verwendet worden ist (d.h. der Löschimpulsvorrat erschöpft ist).
• Eine NAND-Flashspeicherzelle kann durch Anlegen einer positiven hohen Programmierspannung an die Wort-Leitung der zu programmierenden Speicherzelle und durch Anlegen einer mittleren Durchlassspannung an die Speicherzellen in derselben Zeichenfolge programmiert werden, in der eine Programmierung zu unterbinden ist. Ein Anlegen der Programmierspannung verursacht ein Tunneln von Elektronen auf das Floating-Gate, um seinen Zustand von einem ursprünglich gelöschten Zustand in einen programmierten Zustand mit einer negativen Gesamtladung zu ändern. Nach dem Programmieren wird die programmierte Seite typischerweise in einer Leseüberprüfungsoperation gelesen, um sicherzustellen, dass die Programmieroperation erfolgreich war, indem zum Beispiel überprüft wird, dass weniger als eine Schwellenwertanzahl von Speicherzellen in der programmierten Seite Bitfehler enthält. Im Allgemeinen werden die Programmier- und Leseüberprüfungsoperationen auf die Seite angewendet, bis die Leseüberprüfungsoperation erfolgreich war oder bis eine vorbestimmte Anzahl von Programmierimpulsen verwendet worden ist (d.h. der Programmierimpulsvorrat erschöpft ist).
• PAQ stellt eine Reihe von verlustfreien Datenkompressions-Speichermanagern bereit, die durch gemeinschaftliche Entwicklung Ranglisten von mehreren Benchmarks angeführt haben, die das Kompressionsverhältnis (CR) messen. Im Allgemeinen haben verschiedene PAQ-Versionen einen Kontextmischungs-Algorithmus umgesetzt. Eine Kontextmischung steht dadurch mit Prediction by Partial Matching (PPM) in Zusammenhang, dass der Komprimierer/Dekomprimierer in einen Prädiktor und einen arithmetischen Codierer/Decodierer unterteilt ist, sich aber dadurch unterscheidet, dass die Vorhersage des nächsten Symbols unter Verwendung einer gewichteten Kombination von Wahrscheinlichkeitsschätzungen aus einer großen Anzahl von Modellen berechnet wird, die auf verschiedenen Kontexten aufbereitet wurden. Im Gegensatz zu PPM muss ein Kontext in PAQ nicht zusammenhängend sein.
• Im Allgemeinen wird von allen PAQ-Versionen, obwohl sie sich in Details der Modelle und darin unterscheiden, wie Vorhersagen kombiniert und nachbearbeitet werden, jeweils ein Bit vorhergesagt und komprimiert. Wenn die Next-Bit-Wahrscheinlichkeit bestimmt wird, wird das Next-Bit mittels arithmetischer Codierung encodiert. In PAQ1 bis PAQ3 wird jede Vorhersage als ein Paar von Bitzählern dargestellt, die mittels gewichteter Summierung kombiniert werden, wobei längeren Kontexten größere Gewichtungen gegeben werden. In PAQ4 bis PAQ6 werden die Vorhersagen kombiniert (wie in PAQ1 bis PAQ3), doch werden die jedem Modell zugewiesenen Gewichtungen zu Gunsten genauerer Modelle angepasst. In PAQ7 und späteren PAQ-Versionen gibt jedes Modell eine Wahrscheinlichkeit aus (statt eines Paars von Zählern), wobei die Modellwahrscheinlichkeiten unter Verwendung einer Mischeinrichtung eines neuralen Netzwerks kombiniert werden.
• Während Kompressionsalgorithmen für Kontextmischung fast alle bekannten Kompressions-Benchmarks anführen, tendieren Kontextmischungs-Kompressionsalgorithmen aufgrund der großen Anzahl von umgesetzten Kontextmodellen, der Komplexität von neuraler Berechnung und ihrer binären Natur leider dazu, sehr langsam zu sein (zum Beispiel hat der PAQ8I-Algorithmus eine Bandbreite von ungefähr 20 kB/s).
• KURZDARSTELLUNG
• Die offenbarten Techniken verbessern die Umsetzung von Algorithmen zur Kompression/Dekompression einer Kontextmischung in vorteilhafter Weise.
• Eine Technik für nicht binäre Kontextmischung in einem Komprimierer enthält ein Generieren, durch eine Mehrzahl von Kontextmodellen, von Modellvorhersagen in Bezug auf einen Wert eines nächsten Symbols, der encodiert werden soll. Eine Mischeinrichtung generiert eine Gruppe von endgültigen Vorhersagen aus den Modellvorhersagen. Ein arithmetischer Codierer generiert komprimierte Daten auf Grundlage von empfangenen Eingabesymbolen und die Gruppe von endgültigen Vorhersagen. Die empfangenen Eingabesymbole gehören zu einem Alphabet mit einer Größe von mehr als zwei, und die Mischeinrichtung generiert eine Feature-Matrix aus den Modellvorhersagen und schult einen Klassifizierer, der die Gruppe von endgültigen Vorhersagen generiert.
• Gemäß einer weiteren Ausführungsform ist der Klassifizierer ein Maximalentropie-Klassifizierer.
• Gemäß noch einer weiteren Ausführungsform wird der Klassifizierer unter Verwendung von stochastischem Gradientenabfall geschult.
• Gemäß einer anderen Ausführungsform wird der Klassifizierer unter Verwendung von Minibatch-Gradientenabfall geschult.
• Gemäß noch einer weiteren Ausführungsform wird der Klassifizierer unter Verwendung von Noise-Contrastive Estimation geschult.
• In einer weiteren Ausführungsform ist die Mischeinrichtung ein neurales Netzwerk.
• In noch einer weiteren Ausführungsform ist der Klassifizierer ein Maximalentropie-Klassifizierer, der unter Verwendung von stochastischem Gradientenabfall geschult wird.
• Die offenbarten Techniken können als ein Verfahren, ein Datenspeichersystem und/oder ein Programmprodukt (das in einer Speichereinheit gespeicherten Programmcode enthält) umgesetzt werden.
• Figurenliste
• 1A ist ein Blockschaubild auf übergeordneter Ebene für eine Datenverarbeitungsumgebung gemäß einer Ausführungsform;
• 1B ist ein detaillierteres Blockschaubild eines beispielhaften Schnittstellenknotens des Datenspeichersystems von 1A;
• 1C ist ein detaillierteres Blockschaubild einer beispielhaften Flash-Karte des Datenspeichersystems von 1A;
• 2 bis 5 veranschaulichen eine beispielhafte Anordnung eines physischen Speichers in einem NAND-Flashspeichersystem gemäß der vorliegenden Offenbarung;
• 6A stellt eine beispielhafte Umsetzung eines Stripe auf Blockebene gemäß der vorliegenden Offenbarung dar;
• 6B stellt eine beispielhafte Umsetzung eines Stripe auf Seitenebene gemäß der vorliegenden Offenbarung dar;
• 7 veranschaulicht ein beispielhaftes Codewort, das in jeder Datenseite gemäß der vorliegenden Offenbarung gespeichert ist;
• 8 stellt ein beispielhaftes Codewort dar, das in jeder Datenschutzseite gemäß der vorliegenden Offenbarung gespeichert ist;
• 9 ist ein Ablaufplan auf übergeordneter Ebene der Flash-Verwaltungsfunktionen und Datenstrukturen, die von einem Flash-Controller gemäß einer Ausführungsform der vorliegenden Offenbarung verwendet werden;
• 10 stellt eine detailliertere Ansicht eines beispielhaften Flash-Controllers gemäß einer Ausführungsform der vorliegenden Offenbarung dar;
• 11A stellt ein Blockschaubild eines beispielhaften herkömmlichen Komprimierers dar;
• 118 stellt ein Blockschaubild eines beispielhaften herkömmlichen Dekomprimierers dar;
• 12 stellt ein Blockschaubild eines beispielhaften herkömmlichen Prädiktors dar, der Vorhersagen durch Kontextmischung ausführt;
• 13 stellt ein Blockschaubild einer beispielhaften herkömmlichen Mischeinrichtung dar, die logistisches Mischen ausführt;
• 14 stellt ein Blockschaubild eines beispielhaften Komprimierers gemäß einer Ausführungsform der vorliegenden Offenbarung dar;
• 15 stellt eine Tabelle dar, die jeweilige Formeln für drei verschiedene beispielhafte Mischeinrichtungen enthält (d.h. Ausführungsformen „A“, „B“ und „C“), die gemäß der vorliegenden Offenbarung konfiguriert sind;
• 16 stellt ein Blockschaubild einer beispielhaften Mischeinrichtung für die Ausführungsform „A“ von 15 mit einem Alphabet mit vier Eingabesymbolen (d.h. K = 4) dar;
• 17 ist ein logischer Ablaufplan auf übergeordneter Ebene eines beispielhaften Kompressionsprozesses, der eine nicht binäre Kontextmischung gemäß einer Ausführungsform der vorliegenden Offenbarung umsetzt;
• 18 ist ein logischer Ablaufplan auf übergeordneter Ebene eines beispielhaften Dekompressionsprozesses, der eine nicht binäre Kontextmischung gemäß einer Ausführungsform der vorliegenden Offenbarung umsetzt; und
• 19 ist ein logischer Ablaufplan auf übergeordneter Ebene eines beispielhaften Prozesses zum Auswählen von Kontextmodellen für nicht binäre Kontextmischung gemäß einer weiteren Ausführungsform der vorliegenden Offenbarung.
• AUSFÜHRLICHE BESCHREIBUNG
• Gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung wird eine Komprimierer-/Dekomprimierer-Architektur für eine nicht binäre Kontextmischung offenbart, die eine Gesamtheit von Kontextmodellen enthält, die Symbolvorhersagen erzeugen, die als Eingaben in ein Maximalentropiemodell oder ein neurales Netzwerk verteilt werden, das ein Mischen der Symbolvorhersagen ausführt, um eine erlernte Vorhersage zu generieren. Gemäß einer oder mehreren anderen Ausführungsformen der vorliegenden Offenbarung ist die Architektur mit Techniken zur Kontextmodellauswahl verbunden, die die beste Gesamtheit von Kontextmodellen (zum Bereitstellen von Eingaben in ein Maximalentropiemodell oder eine Mischeinrichtung eines neuralen Netzwerks) für eine bestimmte Kundenarbeitslast erlernen. Die offenbarten Kompressionstechniken können eingebettet (z.B. unter Verwendung einer feldprogrammierbaren Gate-Array- (FPGS) Beschleunigung) oder im Hintergrund (z.B. durch Software) umgesetzt werden. Die offenbarten Techniken sind lassen sich umfassend auf Kontextmodellierung mit neuraler Netzwerkmischung anwenden.
• Unter Bezugnahme auf die Figuren und besonderer Bezugnahme auf 1A wird ein Blockschaubild auf übergeordneter Ebene einer beispielhaften Datenverarbeitungsumgebung 100 mit einem Datenspeichersystem 120 veranschaulicht, das konfiguriert ist, um eine Datenkompression/-dekompression gemäß der vorliegenden Offenbarung auszuführen, und die ein nicht flüchtiges Speicherarray hat, wie hierin ferner beschrieben wird. Wie gezeigt, enthält die Datenverarbeitungsumgebung 100 einen oder mehrere Hosts, wie beispielsweise ein Prozessorsystem 102 mit einem oder mehreren Prozessoren 104, die Anweisungen und Daten verarbeiten. Das Prozessorsystem 102 kann zusätzlich einen lokalen Speicher 106 enthalten (z.B. dynamischer Direktzugriffsspeicher (DRAM) oder Platten), der Programmcode, Operanden und/oder Ausführungsergebnisse der Verarbeitung speichern kann, die von dem bzw. den Prozessoren 104 ausgeführt werden. In verschiedenen Ausführungsformen kann das Prozessorsystem 102 zum Beispiel eine mobile Datenverarbeitungseinheit (wie beispielsweise ein Smartphone oder Tablet), ein Laptop oder Desktop-PC-System , ein Servercomputersystem (wie beispielsweise eines aus der POWER^®-Serie, erhältlich von International Business Machines Corporation), oder ein Mainframe-Computersystem sein. Das Prozessorsystem 102 kann auch ein eingebettetes Prozessorsystem unter Verwendung verschiedener Prozessoren sein, wie beispielsweise ARM^®, POWER, Intel X86 oder jeder andere Prozessor in Kombination mit Speicher-Caches, Speicher-Controllern, lokalem Speicher, E/A-Bus-Hubs usw.
• Jedes Prozessorsystem 102 enthält ferner einen Eingabe/Ausgabe- (E/A) Adapter 108, der direkt (d.h. ohne irgendeine dazwischengeschaltete Einheit) oder indirekt (d.h. über mindestens eine Zwischeneinheit) mit einem Datenspeichersystem 120 über einen E/A-Kanal 110 verbunden ist. In verschiedenen Ausführungsformen kann ein E/A-Kanal 110 ein beliebiges oder eine Kombination von bekannten oder zukünftig entwickelten Kommunikationsprotokollen verwenden, darunter zum Beispiel Fibre Channel (FC), FC over Ethernet (FCoE), Internet Small Computer System Interface (iSCSI), InfiniBand, Transport Control Protocol/Internet Protocol (TCP/IP), Peripheral Component Interconnect Express (PCle) usw. E/A-Operationen (IOPs), die über den E/A-Kanal 110 kommuniziert werden, enthalten Lese-IOPs, mit denen ein Prozessorsystem 102 Daten von einem Datenspeichersystem 120 anfordert, und Schreib-IOPs, mit denen ein Prozessorsystem 102 eine Speicherung von Daten in dem Datenspeichersystem 120 anfordert.
• In der veranschaulichten Ausführungsform enthält das Datenspeichersystem 120 mehrere Schnittstellenknoten 122, über die das Datenspeichersystem 120 IOPs empfängt und auf sie über E/A-Kanäle 110 antwortet. Jeder Schnittstellenknoten 122 ist mit jedem von mehreren Redundant Array of Inexpensive Disks- (RAID) Controllern 124 verbunden, um Fehlertoleranz und Lastausgleich zu ermöglichen. Jeder der RAID-Controller 124 ist wiederum mit jeder von mehreren Flash-Karten 126 (z.B. durch einen PCIe-Bus) verbunden, darunter in diesem Beispiel mit NAND-Flashspeichermedien. In anderen Ausführungsformen können andere verlustbehaftete Speichermedien verwendet werden.
• 1B stellt ein detaillierteres Blockschaubild eines Schnittstellenknotens 122 des Datenspeichersystems 120 von 1A dar. Der Schnittstellenknoten 122 enthält eine oder mehrere Schnittstellenkarten 111, die als eine Schnittstelle für die Prozessorsysteme 102 über die E/A-Kanäle 110 dienen und mit einer hostseitigen Vermittlungsstruktur 112 verbunden sind. Die hostseitige Vermittlungsstruktur 112 wirkt als Umschalter und bearbeitet alle Datenübertragungen zwischen den Schnittstellenkarten 111 und Verarbeitungseinheiten in dem Schnittstellenknoten 122, und zwar einem Universalprozessor (GPP) auf Steuerebene 113, einem GPP auf Datenebene 116 und einem Prozessor auf Datenebene 117. Typischerweise besteht die hostseitige Vermittlungsstruktur 112 aus einem PCIe-Switch, doch können auch andere Switch-Technologien verwendet werden. Der Prozessor auf Datenebene 117 ist ein Sonderprozessor, der zum Beispiel durch eine anwendungsspezifische integrierte Schaltung (ASIC) oder ein feldprogrammierbares Gate-Array (FPGA) umgesetzt werden kann. Der GPP auf Steuerebene 113, der GPP auf Datenebene 116 und der Prozessor auf Datenebene 117 sind alle mit dem Speicher 114 verbunden, der als zwischen diesen Komponenten gemeinsam genutzter Speicher, als separate Speicher oder als Kombination davon umgesetzt werden kann.
• Der Prozessor auf Datenebene 117 setzt eine Fingerabdruck-Engine 118 um, die Fingerabdrücke für empfangene Datenseiten generiert, die in die Flash-Karten 126 geschrieben oder aus diesen ausgelesen werden sollen. Der Prozessor auf Datenebene 117 kann ferner auf eine Fingerabdruck-Nachschlagtabelle (LUT) 115, die im Speicher 114 gespeichert ist, entweder direkt oder durch Datenübertragen mit dem GPP auf Datenebene 116 oder dem GPP auf Steuerebene 113 zugreifen. Fingerabdrücke für empfangene Datenseiten können Hash-Werte, CRCs (zyklische Redundanzprüfungen) oder eine Kombination aus Hash-Werten und CRCs enthalten. Die Fingerabdruck-Engine 118 (oder eine andere Logik im Prozessor auf Datenebene 117) kann auch konfiguriert werden, um komprimierte Seitengrößen von empfangenen Datenseiten zu bestimmen. Die Fingerabdruck-LUT 115 speichert Fingerabdrücke für Datenseiten, die in den Flash-Karten 126 gespeichert sind. Es sollte klar sein, dass die Fingerabdruck-LUT 115 zu jeder gegebenen Zeit aufgrund von Speichergrößenbeschränkungen nur Fingerabdrücke für einige der Datenseiten speichern kann, die in den Flash-Karten 126 gespeichert sind.
• In Ausführungsformen, in denen der Prozessor auf Datenebene 117 in einem FPGA umgesetzt ist, kann der GPP auf Steuerebene 113 den Prozessor auf Datenebene 117 beim Hochfahren des Datenspeichersystems 120 programmieren und konfigurieren. Der GPP auf Datenebene 116 und der GPP auf Steuerebene 113 steuern den Prozessor auf Datenebene 117 und greifen auf die Flash-Karten 126 entweder indirekt über den Prozessor auf Steuerebene 117 oder direkt über eine plattenseitige Vermittlungsstruktur 119 zu. Der GPP auf Steuerebene 113 führt Systemverwaltungsfunktionen sowie Dienste auf höherer Ebene wie Snapshots, Thin Provisioning (reduzierte Bereitstellung) und Deduplizierung aus. Der GPP auf Datenebene 116 führt protokollspezifische Funktionen aus. Der GPP auf Steuerebene 113, der GPP auf Datenebene 116 und der Prozessor auf Datenebene 117 sind mit dem RAID-Controller 124 über die plattenseitige Vermittlungsstruktur 119 verbunden, die typischerweise aus einem PCIe-Switch besteht, es können jedoch auch andere Switch-Technologien verwendet werden. 1B veranschaulicht des Weiteren den GPP auf Steuerebene 113 und den Prozessor auf Datenebene 117, die über andere Schnittstellenknoten 122 in dem Datenspeichersystem 120 verbunden sind, um Ausfallsicherungsszenarios zu bearbeiten oder andere Datensynchronisationsfunktionen auszuführen.
• 1C stellt ein detaillierteres Blockschaubild einer Flash-Karte 126 des Datenspeichersystems 120 von 1A dar. Die Flash-Karte 126 enthält ein Gateway 130, das als Schnittstelle zwischen der Flash-Karte 126 und RAID-Controllern 124 dient. Das Gateway 130 ist mit einem Universalprozessor (GPP) 132 verbunden, der konfiguriert werden kann (z.B. durch Programmcode), verschiedene Verwaltungsfunktionen auszuführen, wie beispielsweise ein Vorverarbeiten von IOPs, die von dem Gateway 130 empfangen wurden und/oder ein Planen einer Bedienung der IOPs durch die Flash-Karte 126. Ein GPP 132 ist mit einem GPP-Speicher 134 verbunden (z.B. dynamischer Direktzugriffsspeicher (DRAM) oder magnetoresistiver Direktzugriffsspeicher (MRAM)), der praktischerweise Daten puffern kann, die im Verlauf ihrer Verarbeitung durch den GPP 132 erstellt, referenziert und/oder modifiziert wurden.
• Das Gateway 130 ist ferner mit mehreren Flash-Controllern 140 verbunden, von denen jeder ein jeweiliges NAND-Flashspeichersystem 150 steuert. Die Flash-Controller 140 können zum Beispiel durch eine anwendungsspezifische integrierte Schaltung (ASIC) oder ein feldprogrammierbares Gate-Array (FPGA) mit einem dazugehörigen Flash-Controllerspeicher 142 (z.B. DRAM) umgesetzt werden. In Ausführungsformen, in denen Flash-Controller 140 mit einem FPGA umgesetzt sind, kann der GPP 132 die Flash-Controller 140 beim Hochfahren des Datenspeichersystems 120 programmieren und konfigurieren. Nach dem Hochfahren empfangen die Flash-Controller 140 im normalen Betrieb Lese- und Schreib-IOPs vom Gateway 130, die ein Lesen von Daten, die in dem NAND-Flashspeichersystem 150 gespeichert sind, und/oder ein Speichern von Daten in dem NAND-Flashspeichersystem 150 anfordern. Die Flash-Controller 140 bedienen diese IOPs, indem sie zum Beispiel auf die NAND-Flashspeichersysteme 150 zugreifen, um die angeforderten Daten aus den NAND-Flashspeichersystemen 150 auszulesen oder in diese zu schreiben, oder indem sie auf einen oder mehrere Lese- und/oder Schreib-Caches (nicht in 1C veranschaulicht) zugreifen, die NAND-Flashspeichersystemen 150 zugehörig sind. Zum Beispiel können NAND-Flashspeichersysteme 150 eine Kombination von Datenseiten und eine oder mehrere Fingerabdruck-Metadaten- (MD) Seiten speichern, die Fingerabdruck-Metadaten für eine oder mehrere Datenseiten bereitstellen. In einer alternativen Ausführungsform können Fingerabdruck-MD in einem anderen Speicher als Datenseiten gespeichert werden.
• Die Flash-Controller 140 setzen eine Flash Translation Layer (FTL) um, die eine logisch-zu-physische Adressumsetzung bereitstellt, um den Zugriff auf bestimmte Speicherplätze in NAND-Flashspeichersystemen 150 zu ermöglichen. Im Allgemeinen enthält eine IOP, die von einem Flash-Controller140 von einer Hosteinheit empfangen wird, wie beispielsweise ein Prozessorsystem 102, die logische Blockadresse (LBA), unter der auf die Daten zugegriffen (gelesen oder geschrieben) werden soll, und im Fall einer Schreib-IOP die Schreibdaten in das Datenspeichersystem 120 geschrieben werden sollen. Die IOP kann auch die Menge (oder Größe) der Daten angeben, auf die zugegriffen werden soll. Andere Informationen, die von dem Protokoll und den durch das Datenspeichersystem 120 unterstützten Funktionen abhängen, können ebenfalls kommuniziert werden. Wie dem Fachmann bekannt ist, ist ein NAND-Flashspeicher wie derjenige, der in NAND-Flashspeichersystemen 150 verwendet wird, durch seine Konstruktion derart eingeschränkt, dass die kleinste Dateneinheit, auf die von einer Lese- oder Schreib-IOP zugegriffen werden kann, auf die Größe einer einzelnen Flashspeicherseite festgelegt ist, zum Beispiel 16 Kilobyte (kB). Die von der Hosteinheit bereitgestellte LBA entspricht einer logischen Seite in einem logischen Adressraum, wobei die logische Seite typischerweise eine Größe von vier (4) Kilobyte hat. Dementsprechend kann mehr als eine logische Seite in einer physischen Flashseite gespeichert werden. Die FTL übersetzt diese LBA in eine physische Adresse, die einer entsprechenden physischen Speicherstelle in einem NAND-Flashspeichersystem 150 zugewiesen ist.
• Die Flash-Controller 140 können eine Adressumsetzung ausführen und/oder Zuordnungen zwischen logischen und physischen Adressen in einer logisch-zu-physischen Umsetzungsdatenstruktur speichern, wie beispielsweise eine logisch-zu-physische Umsetzungs- (LPT) Tabelle, die praktischerweise im Flash-Controllerspeicher 142 gespeichert werden kann. Eine LPT-Tabelle kann auch konfiguriert werden, um komprimierte Seitengrößen von Datenseiten, die in dem NAND-Flashspeichersystem 150 gespeichert sind, und sogar noch ihre CRC-Werte zu speichern.
• NAND-Flashspeichersysteme 150 können viele Formen in verschiedenen Ausführungsformen annehmen. Unter folgender Bezugnahme auf 2 bis 5 wird eine beispielhafte Anordnung von physischem Speicher in einem NAND-Flashspeichersystem 150 gemäß einer beispielhaften Ausführungsform dargestellt.
• Wie in 2 gezeigt, kann ein NAND-Flashspeichersystem 150 aus zweiunddreißig (32) einzeln adressierbaren NAND-Flashspeicher-Speichereinheiten gebildet werden. In dem veranschaulichten Beispiel nimmt jede der Flashspeicher-Speichereinheiten M0a bis M15b die Form eines auf einer Platine montierten Flashspeichermoduls an, das fähig ist, zwei oder mehr Bits pro Zelle zu speichern. Somit können Flashspeichermodule mit Single Level Cell-(SLC), Multi-Level Cell- (MLC), Three Level Cell- (TLC) oder Quad Level Cell- (QLC) Speicher umgesetzt werden. Die zweiunddreißig NAND-Flashspeichermodule sind in sechzehn Zweiergruppen, (M0a, M0b) bis (M15a, M15b) angeordnet. Für Zwecke des physischen Adressierplans bildet jede Gruppe von zwei Modulen einen „Pfad“, der manchmal auch als „Kanal“ bezeichnet wird, sodass das NAND-Flashspeichersystem 150 sechzehn Kanäle oder Pfade enthält (Pfad0 bis Pfad15).
• In einer bevorzugten Ausführungsform hat jeder der einzelnen Pfade einen jeweils zugehörigen Bus, der ihn mit dem zugehörigen Flash-Controller 140 verbindet. Somit kann der Flash-Controller 140 durch eine Weiterleitung seiner Datenübertragungen zu einem der spezifischen Datenübertragungsbusse seine Datenübertragungen zu einem der Pfade von Speichermodulen weiterleiten. Da jeder Datenübertragungsbus für einen bestimmten Pfad von den Datenübertragungsbussen für die anderen Pfade unabhängig ist, kann der Flash-Controller 140 Befehle ausgeben und gleichzeitig Daten über die verschiedenen Datenübertragungsbusse senden oder empfangen, was dem Flash-Controller 140 ermöglicht, gleichzeitig oder zumindest fast gleichzeitig auf die Flashspeichermodule zuzugreifen, die den einzelnen Pfaden entsprechen.
• Unter folgender Bezugnahme auf 3 wird eine beispielhafte Ausführungsform eines Flashspeichermoduls 300 veranschaulicht, die zum Umsetzen von beliebigen der Flashspeichermodule M0a bis M15b von 2 verwendet werden kann. Wie in 3 gezeigt, sind die von dem Flashspeichermodul 300 bereitgestellten physischen Speicherplätze des Weiteren in physische Speicherplätze unterteilt, die über Chip Enables (Chip-Freigabe) (CEs) adressiert und/oder identifiziert werden können. In dem Beispiel von 3 ist der physische Speicher von jedem Flashspeicherchip 300 in vier Chip-Enables (CE0, CE1, CE2 und CE3) unterteilt, die jeweils eine jeweilige CE-Leitung haben, die durch den Flash-Controller 140 aktiviert wird, um Zugang zu oder von den physischen Speicherstellen in der entsprechenden CE zu ermöglichen. Jede CE ist wiederum in mehrere Chips unterteilt (z.B. Die0 und Die1), die jeweils zwei Ebenen haben (z.B. Ebene0 und Ebene1). Jede Ebene stellt eine Sammlung von Blöcken dar (im Folgenden beschrieben), die aufgrund des physischen Layouts der Flashspeicherchips einander physisch zugeordnet sind, und die eine gemeinsame Schaltung (z.B. E/A-Puffer) für die Ausführung verschiedener Operationen nutzen, wie beispielsweise Lese- und Schreib-Operationen.
• Wie ferner in 4 bis 5 gezeigt, enthält eine beispielhafte Ebene 400, die zum Umsetzen einer beliebigen der Ebenen in dem Flashspeichermodul 300 von 3 verwendet werden kann, zum Beispiel 1024 oder 2048 Blöcke von physischem Speicher. Es ist anzumerken, dass Hersteller oft einige zusätzlichen Blöcke hinzufügen, da einige Blöcke frühzeitig ausfallen könnten. Im Allgemeinen ist ein Block eine Sammlung von physischen Seiten, die einander typischerweise physisch zugeordnet sind. Diese Zuordnung ist derart, dass ein Block als die kleinste Granularität von physischen Speicherplätzen definiert wird, die in dem NAND-Flashspeichersystem 150 gelöscht werden können. In der Ausführungsform von 5 enthält jeder Block 500 zum Beispiel 256 oder 512 physische Seiten, wobei eine physische Seite als kleinste einzeln adressierbare Dateneinheit für Lese- und Schreibzugriff definiert wird. In dem beispielhaften System hat jede physische Datenseite eine allgemeine Kapazität (z.B. 16kB) für Datenspeicherung plus zusätzlichem Speicher für Metadaten, der im Folgenden ausführlicher beschrieben wird. Somit werden Daten in ein NAND-Flashspeichersystem 150 auf einer seitenweisen Grundlage geschrieben oder daraus ausgelesen, aber auf einer blockweisen Grundlage gelöscht.
• Wenn das NAND-Flashspeichersystem 150 in einer Speichertechnologie umgesetzt wird, die mehrere Bits pro Zelle unterstützt, ist es üblich. dass mehrere physische Seiten jedes Blocks 500 in derselben Gruppe von Speicherzellen umgesetzt werden. Wenn zum Beispiel von 512 physischen Seiten pro Block 500, wie in 5 gezeigt, und zwei Bits pro Speicherzelle ausgegangen wird (d.h. der NAND-Flashspeicher 150 ist im MLC-Speicher umgesetzt), können Seite0 bis Seite255 (die niedrigwertigeren Seiten) unter Verwendung des ersten Bits einer vorgegebenen Gruppe von Speicherzellen umgesetzt werden, und Seite256 bis Seite511 (die höherwertigeren Seiten) können unter Verwendung des zweiten Bits der vorgegebenen Gruppe von Speicherzellen umgesetzt werden. Die tatsächliche Reihenfolge von niedrigwertigeren und höherwertigen Seiten kann verschachtelt sein und hängt vom Hersteller ab. In vielen Fällen kann die Lebensdauer von Seiten in einem Block 500 sehr stark variieren, und in einigen Fällen wird diese Schwankung insbesondere zwischen niedrigwertigeren Seiten (die allgemein eine geringere Lebensdauer haben können), und höherwertigen Seiten deutlich (die im Allgemeinen eine höhere Lebensdauer haben können).
• Wie des Weiteren in 5 gezeigt, enthält jeder Block 500 bevorzugt Blockstatusinformationen (BSI) 502, die den Zustand jeder physischen Seite in diesem Block 500 als stillgelegt (d.h. nicht mehr zum Speichern von Benutzerdaten verwendet) oder nicht stillgelegt (d.h. aktiv oder immer noch zum Speichern von Benutzerdaten verwendbar) angibt. In verschiedenen Umsetzungen können die BSI 502 in einer einzigen Datenstruktur (z.B. Vektor oder Tabelle) im Block 500 gesammelt, im Block 500 verteilt (z.B. als ein oder mehrere Bits von Metadaten, die an jede physische Seite angehängt werden) und/oder anderswo in dem Datenspeichersystem 120 verwaltet werden. Zum Beispiel werden in der in 9 veranschaulichten und im Folgenden erläuterten Ausführungsform die Seitenstatusinformationen aller Blöcke 500 in einem NAND-Flashspeichersystem 150 in einer Datenstruktur auf Systemebene gesammelt, zum Beispiel einer Seitenstatustabelle (PST) 946, die im GPP-Speicher 134 oder einem Flash-Controllerspeicher 142 gespeichert wird.
• Da die durch das Datenspeichersystem 120 umgesetzte FTL den logischen Adressraum isoliert, der vom physischen Speicher im NAND-Flashspeichersystem 150 für Hosteinheiten verfügbar gemacht wird, muss die Größe des NAND-Flashspeichersystems 150 nicht gleich der Größe des logischen Adressraums sein, der für Hosteinheiten ausgewiesen wird. In den meisten Ausführungsformen ist es von Vorteil, einen logischen Adressraum auszuweisen, der kleiner als der insgesamt verfügbare physische Speicher ist (d.h. das NAND-Flashspeichersystem 150 zu überversorgen). Eine Überversorgung auf diese Weise stellt sicher, dass physische Speicherressourcen verfügbar sind, wenn der logische Adressraum voll ausgeschöpft ist, selbst wenn eine bestimmte Menge ungültiger Daten vorhanden ist, wie oben beschrieben. Zusätzlich zu ungültigen Daten, die noch nicht zurückgeladen worden sind, kann der überversorgte Raum zum Sicherstellen verwendet werden, dass genügend logischer Raum vorhanden ist, selbst wenn Speicherfehler und der Speicher-Overhead vorhanden sind, die sich aus der Verwendung von Datenschutzregelungen ergeben, wie beispielsweise Fehlerkorrekturcode (ECC), zyklische Redundanzprüfungen (CRC) und Parität.
• In einigen Ausführungsformen werden Daten in das NAND-Flashspeichersystem 150 mit jeweils einer physischen Seite nach der anderen geschrieben. In anderen Ausführungsformen, in denen eine robustere Fehlerbehebung gewünscht wird, werden Daten in Gruppen von zugehörigen physischen Seiten des NAND-Flashspeichersystems 150 geschrieben, auf die hierin als „Stripes auf Seitenebene“ verwiesen wird. In einer offenbarten Ausführungsform sind alle Seiten eines Stripe auf Seitenebene verschiedenen Pfaden zugehörig, um eine hohe Schreib-Bandbreite zu erreichen. Da in vielen Umsetzungen die kleinste Löscheinheit ein Block ist, können Stripes auf Seitenebene zu einem Stripe auf Blockebene gruppiert werden, wie in 6A gezeigt, wobei jeder Block in dem Stripe auf Blockebene einem anderen Pfad zugehörig ist. Wenn ein Stripe auf Blockebene aufgebaut wird, kann jeder freie Block eines Pfads gewählt werden, aber bevorzugt haben alle Blöcke in demselben Stripe auf Blockebene denselben oder einen ähnlichen Integritätsgrad. Es ist anzumerken, dass die Blockauswahl weiter darauf eingeschränkt werden kann, aus derselben Ebene, demselben Chip oder derselben Chip-Freigabe zu kommen. Die Längen der Stripes auf Blockebene können und werden bevorzugt variieren, aber in einer Ausführungsform, in der das NAND-Flashspeichersystem 150 16 Pfade enthält, enthält jeder Stripe auf Blockebene zwischen zwei und sechzehn Blöcke, wobei jeder Block aus einem anderen Pfad stammt. Weitere Details zum Aufbau von Stripes auf Blockebene mit variierenden Längen sind in den U.S.-Patentschriften 8 176 284 ; 8 176 360 ; 8 443 136 ; und 8 631 273 zu finden, die hierin mittels Verweis in ihrer Gesamtheit aufgenommen sind.
• Wenn ein Block aus jedem Pfad ausgewählt und ein Stripe auf Blockebene gebildet worden ist, werden Stripes auf Seitenebene bevorzugt aus physischen Seiten mit derselben Seitennummer aus allen Blöcken in dem Stripe auf Blockebene gebildet. Während die Längen der verschiedenen Stripes auf Seitenebene, die in dem NAND-Flashspeichersystem 150 gespeichert sind, variieren können und bevorzugt variieren werden, enthält in einer Ausführungsform jeder Stripe auf Seitenebene eine bis fünfzehn Datenseiten mit Schreibdaten (die typischerweise von einer Hosteinheit bereitgestellt werden), und eine zusätzliche Seite (eine „Datenschutzseite“), die zum Speichern von Datenschutzinformationen für die Schreibdaten verwendet wird. Zum Beispiel veranschaulicht 6B einen beispielhaften Stripe auf Seitenebene 610 mit N Datenseiten (d.h. Dpage00 bis DpageN-1) und eine Datenschutzseite (d.h. PpageN). Die Datenschutzseite kann auf jedem Pfad des Stripe auf Seitenebene positioniert werden, der eine nicht stillgelegte Seite enthält, befindet sich aber typischerweise auf demselben Pfad für alle Stripes auf Seitenebene desselben Stripe auf Blockebene, um Metadaten-Informationen zu minimieren. Das Hinzufügen einer Datenschutzseite wie veranschaulicht erfordert, dass für alle Stripes auf Seitenebene desselben Stripe auf Blockebene gleichzeitig eine Garbage Collection (Abfalldatensammlung) ausgeführt wird. Nach Abschluss der Garbage Collection des Stripe auf Blockebene kann der Stripe auf Blockebene aufgelöst werden, und jeder Block kann in die relevante Ready-to-Use- (RTU) Warteschlange gestellt werden, wie im Folgenden erläutert. Ähnlich wie bei den logischen Datenseiten, die in Stripes auf Seitenebene eines Stripe auf Blockebene gestellt werden, können auch Fingerabdruck-MD-Seiten dort abgelegt werden. Logische Datenseiten und Fingerabdruck-DM-Seiten können vermischt sein. Tatsächlich ist es möglich, dass die Flash-Karte 126 den Unterschied zwischen regulären logischen Datenseiten und Fingerabdruck-MD-Seiten nicht wirklich kennt. Die Fingerabdruck-MD-Seiten können auf einem dedizierten Metadaten-Datenträger gespeichert werden, der durch die Schnittstellenknoten 122 gesteuert wird und für das Prozessorsystem 102 nicht sichtbar ist. Da die Flash-Karten 126 keinerlei Kenntnis über Datenträger haben, werden Operationen von Fingerabdruck-MD-Seiten als reguläre Lese- und Schreiboperationen behandelt.
• 7 veranschaulicht ein beispielhaftes Format eines Codeworts, das in jeder Datenseite in dem Stripe auf Seitenebene 610 von 6B gespeichert ist. Typischerweise wird eine positive ganzzahlige Anzahl von Codewörtern, zum Beispiel 2 oder 3, in jeder Datenseite gespeichert, aber eine alternative Ausführungsform kann auch ein einzelnes Codewort in einer Datenseite speichern. In diesem Beispiel enthält jedes Codewort 700 ein Datenfeld 702 sowie weitere Felder für Metadaten, die die Datenseite beschreiben. Abhängig von der Größe des Codeworts enthält das Datenfeld 702 Daten für eine oder mehrere logische Seiten. In einer weiteren Ausführungsform kann es auch Bruchteile von Daten von logischen Datenseiten enthalten. In dem veranschaulichten Beispiel enthalten Metadatenfelder ein LBA-Feld 704, das die im Codewort 700 gespeicherten LBAs enthält, ein CRC-Feld 706, das den CRC-Wert enthält, der für die Kombination des Datenfelds 702 und LBA-Felds 704 berechnete worden ist, und ein ECC-Feld 708, das einen ECC-Wert enthält, der in dem veranschaulichten Beispiel aus einer Kombination der Inhalte des Datenfelds 702, des LBA-Felds 704 und des CRC-Felds706 berechnet worden ist. In dem Fall, in dem das Datenfeld 702 Bruchteile von logischen Datenseiten enthält, enthält das LBA-Feld 704 des Weiteren Informationen, auf denen Bruchteile von logischen Datenseiten in dem Datenfeld 702 gespeichert sind.
• 8 veranschaulicht ein beispielhaftes Format eines Codeworts in der Datenschutzseite des Stripe auf Seitenebene 610 von 6B. In einer Ausführungsform speichert jede Datenschutzseite eine positive ganzzahlige Anzahl von Codewörtern, aber eine alternative Ausführungsform einer Datenschutzseite kann auch ein einzelnes Codewort speichern. In dem dargestellten Beispiel enthält ein Datenschutz-Codewort 800 ein XOR-Datenfeld 802, das das bitweise EXKLUSIV-ODER (XOR) der Inhalte der Datenfelder 702 der Codewörter 700 in dem Stripe auf Seitenebene 610 enthält. Das Datenschutz-Codewort 800 enthält ferner ein LBA-XOR-Datenfeld 804, das das bitweise XOR der LBA-Felder 704 der Codewörter 700 in dem Stripe auf Seitenebene 610 enthält. Das Datenschutz-Codewort 800 enthält schließlich ein CRC-Feld 806 und ECC-Feld 808 zum jeweiligen Speichern eines CRC-Werts und eines ECC-Werts für das Datenschutz-Codewort 800. Ein derartiges Schutzschema wird im Allgemeinen als RAID 5 bezeichnet, da das Paritätsfeld sich nicht immer auf einer bestimmten Flash-Ebene befindet. Es sollte jedoch klar sein, dass alternative Datenschutzschemas wie beispielsweise Reed-Solomon alternativ oder zusätzlich verwendet werden können
• Die Formate für Datenseiten und die oben beschriebenen Datenschutzseiten schützen Daten, die in einem Stripe auf Seitenebene gespeichert sind, unter Verwendung mehrerer verschiedener Datenschutzmechanismen. Zunächst gestattet die Verwendung von ECC-Bits in jedem Datencodewort einer Datenseite in einer Flash-Seite die Korrektur einer bestimmten Anzahl von Bitfehlern in dem Codewort. Abhängig von dem verwendeten ECC-Verfahren können eventuell Hunderte von Bits oder sogar Tausende von Bits in einer NAND-Flash-Seite korrigiert werden. Nach dem Ausführen einer ECC-Prüfung und Korrektur wird das korrigierte CRC-Feld zum Validieren der korrigierten Daten verwendet. Zusammen verwendet ermöglichen diese beiden Mechanismen die Korrektur von relativ harmlosen Fehlern und die Erfassung schwerwiegenderer Fehler unter Verwendung nur lokaler seiteninterner Informationen. Sollte ein nicht korrigierbarer Fehler in einer Datenseite auftreten, zum Beispiel aufgrund dessen, dass ein Speichern der Datenseite durch die verwendete physische Seite fehlgeschlagen ist, können die Inhalte des Datenfelds und des LBA-Felds der fehlgeschlagenen Datenseite aus den anderen Datenseiten und der Datenschutzseite für den Stripe auf Seitenebene wiederhergestellt werden.
• Während die physischen Speicherplätze, in denen die Datenseiten und die Datenschutzseite eines Stripe auf Seitenebene in dem NAND-Flashspeichersystem 150 variieren, werden in einer Ausführungsform die Datenseiten und die Datenschutzseite, die einen bestimmten Stripe auf Seitenebene aufweisen, bevorzugt in physischen Speicherplätzen gespeichert, die ausgewählt werden, um den Gesamtbetrieb des Datenspeichersystems 120 zu optimieren. Zum Beispiel werden in einigen Ausführungsformen die Datenseiten und die Datenschutzseite, die einen Stripe auf Seitenebene aufweisen, so gespeichert, dass verschiedene physische Pfade verwendet werden, um jede der Datenseiten und die Datenschutzseite zu speichern. Derartige Ausführungsformen unterstützen einen effizienten Zugriff auf einen Stripe auf Seitenebene, da der Flash-Controller 140 auf alle Seiten mit Daten, die den Stripe auf Seitenebene aufweisen, gleichzeitig oder nahezu gleichzeitig zugreifen kann. Es ist anzumerken, dass die Zuweisung von Seiten zu Pfaden nicht der Reihe nach erfolgen muss (d.h. Datenseiten können in jedem Pfad in beliebiger Reihenfolge gespeichert werden), und sofern ein Stripe auf Seitenebene kein Stripe voller Länge auf Seitenebene ist (z.B. fünfzehn Datenseiten und eine Datenschutzseite enthält), müssen die zum Speichern des Stripe auf Seitenebene verwendeten Pfade nicht benachbart sein.
• Nach der Beschreibung der allgemeinen physischen Struktur und des Betriebs einer beispielhaften Ausführungsform eines Datenspeichersystems 120 werden im Folgenden bestimmte betriebliche Aspekte des Datenspeichersystems 120 unter Bezugnahme auf 9 beschrieben, die ein Übersichtsablaufplan der Flash-Verwaltungsfunktionen und Datenstrukturen ist, die durch den GPP 132 und/oder die Flash-Controller 140 gemäß einer Ausführungsform verwendet werden.
• Wie oben angemerkt, gestattet das Datenspeichersystem 120 im Allgemeinen externen Einheiten keine direkte Adressierung und/oder den direkten Zugriff auf physische Speicherplätze in NAND-Flashspeichersystemen 150. Stattdessen ist das Datenspeichersystem 120 im Allgemeinen so konfiguriert, dass es für externe Einheiten einen einzigen zusammenhängenden logischen Adressraum darstellt, wodurch es Hosteinheiten ermöglicht wird, Daten aus LBAs in dem logischen Adressraum auszulesen und in diese zu schreiben, wobei den Flash-Controllern 140 und dem GPP 132 gestattet wird, zu steuern, wo sich die den verschiedenen LBAs zugehörigen Daten in den physischen Speicherplätzen befinden, die NAND-Flashspeichersysteme 150 aufweisen. Auf diese Weise können die Leistung und Langlebigkeit von NAND-Flashspeichersystemen 150 intelligent verwaltet und optimiert werden. In der veranschaulichten Ausführungsform verwaltet jeder Flash-Controller 140 die logisch-zu-physische Umsetzungsdatenstruktur, wie beispielsweise eine logisch-zu-physische Umsetzungs- (LPT) Tabelle 900, die in dem zugehörigen Flash-Controllerspeicher 142 gespeichert werden kann. Wie oben erwähnt, kann eine LPT-Tabelle, wie beispielsweise die LPT-Tabelle 900, auch konfiguriert werden, um komprimierte Seitengrößen von Datenseiten zu speichern, die in NAND-Flashspeichersystemen 150 gespeichert sind, um eine Datendeduplizierung zu unterstützen.
• Ein Flash-Verwaltungscode, der auf dem GPP 132 ausgeführt wird, verfolgt gelöschte Blöcke des NAND-Flashspeichersystems 150, die zur Verwendung in Ready-to-Use- (RTU) Warteschlangen 906 bereit sind, die zum Beispiel im GPP-Speicher 134 gespeichert werden können. In der dargestellten Ausführungsform verwaltet der auf dem GPP 132 ausgeführte Verwaltungscode bevorzugt eine oder mehrere RTU-Warteschlangen 906 pro Kanal, und eine Kennung für jeden gelöschten Block, der erneut verwendet werden soll, wird in eine der RTU-Warteschlangen 906 gestellt, die seinem Kanal entsprechen. Zum Beispiel enthalten die RTU-Warteschlangen 906 in einer Ausführungsform für jeden Kanal eine jeweilige RTU-Warteschlange 906 für jede einer Mehrzahl von Block-Integritätsgraden. In verschiedenen Umsetzungen wurde festgestellt, dass zwischen 2 und 8 RTU-Warteschlangen 906 pro Pfad (und eine entsprechende Anzahl von Block-Integritätsgraden) ausreichend sind.
• Eine Aufbaufunktion von Stripes auf Blockebene 920, die durch den Flash-Verwaltungscode ausgeführt wird, der auf dem GPP 132 ausgeführt wird, baut neue Stripes auf Blockebene zum Speichern von Daten und zugehörigen Paritätsinformationen aus den gelöschten Blöcken auf, die sich in den RTU-Warteschlangen 906 befinden. Wie oben unter Bezugnahme auf 6A angemerkt, werden Stripes auf Blockebene bevorzugt aus Blöcken desselben oder eines ähnlichen Integritätsgrads (d.h. erwartete restliche nützliche Lebensdauer) gebildet, die sich in verschiedenen Kanälen befinden, was bedeutet, dass die Aufbaufunktion von Stripes auf Blockebene 920 einen Stripe auf Blockebene praktischerweise aufbauen kann, indem jeder Block des neuen Stripe auf Blockebene aus entsprechenden RTU-Warteschlangen 906 von verschiedenen Kanälen genommen wird. Der neue Stripe auf Blockebene wird dann für den Flash-Controller 140 zur Datenablage in die Warteschlange gestellt.
• In Reaktion auf eine von einem Host empfangene Schreib-IOP, wie beispielsweise von einem Prozessorsystem 102, bestimmt eine Datenablagefunktion 910 des Flash-Controllers 140 durch Verweis auf die LPT-Tabelle 900, ob die Ziel-LBA(s), die in der Schreibanforderung angegeben ist bzw. sind, derzeit einer bzw. mehreren physischen Speicherseiten im NAND-Flashspeichersystem 150 zugehörig ist oder sind, und falls dies der Fall ist, den Zustand jeder Datenseite ändert, die derzeit einer Ziel-LBA zugehörig ist, um anzugeben, dass sie nicht mehr gültig ist. Außerdem weist die Datenablagefunktion 910 einen Stripe auf Seitenebene zu, falls erforderlich, um die Schreibdaten der Schreib-IOP und alle nicht aktualisierten Daten (d.h. in dem Fall, in dem die Schreibanforderung kleiner als eine logische Seite ist, sind immer noch gültige Daten vorhanden, die in einer Lesen-Modifizieren-Schreiben-Form bearbeitet werden müssen) aus einem bestehenden Stripe auf Seitenebene zu speichern, sofern vorhanden, der durch die Schreib-IOP als Ziel angegeben wird, und/oder die Schreibdaten der Schreib-IOP und alle nicht aktualisierten (d.h. immer noch gültigen) Daten aus einem bestehenden Stripe auf Seitenebene, sofern vorhanden, der durch die Schreib-IOP als Ziel angegeben wird, auf einem bereits zugewiesenen Stripe auf Seitenebene zu speichern, auf dem noch freier Speicherplatz ist. Der Stripe auf Seitenebene kann entweder von einem Stripe auf Blockebene, der bereits zum Speichern von Daten zugewiesen wurde, oder von einem neuen Stripe auf Blockebene zugewiesen werden, der durch die Aufbaufunktion von Stripes auf Blockebene 920 aufgebaut wurde. In einer bevorzugten Ausführungsform kann die Zuweisung des Stripe auf Seitenebene auf Grundlage der Integrität der Blöcke, die zur Zuweisung verfügbar sind, und der „Durchgänge“ (d.h. der geschätzten oder gemessenen Schreibzugriffhäufigkeit) der LBA der Schreibdaten erfolgen. Die Datenablagefunktion 910 schreibt anschließend die Schreibdaten, die zugehörigen Metadaten (z.B. CRC- und ECC-Werte) für jedes Codewort in jede Seite des Stripe auf Seitenebene und Paritätsinformationen für den Stripe auf Seitenebene in den zugewiesenen Stripe auf Seitenebene. Die zugehörigen Metadaten und Paritätsinformationen können in den Speicher geschrieben werden, sobald genügend Host-Daten in dem Stripe auf Seitenebene abgelegt worden sind. Der Flash-Controller 140 aktualisiert ebenfalls die LPT-Tabelle 900, um die verwendete physische Seite bzw. verwendeten physischen Seiten zum Speichern der Schreibdaten mit der bzw. den durch die Host-Einheit angegebenen LBA(s)zu speichern. Danach kann der Flash-Controller 140 auf die Daten zugreifen, um vom Host gelesene IOPs unter Verweis auf die LPT-Tabelle 900 zu bedienen, wie ferner in 9 veranschaulicht wird.
• Sobald alle Seiten in einen Stripe auf Blockebene geschrieben worden sind, stellt der Flash-Controller 140 den Stripe auf Blockebene in eine von belegten Block-Warteschlangen 902, die der im GPP 132 ausgeführte Flash-Verwaltungscode verwendet, um die Garbage Collection zu ermöglichen. Wie oben angemerkt, werden Seiten durch den Schreibprozess ungültig gemacht, und daher werden Abschnitte des NAND-Flashspeichersystems 150 unbenutzt. Ein zugehöriger Flash-Controller 140 (und/oder der GPP 132) muss diesen Raum durch eine Abfalldatensammlung, die durch einen Garbage Collector 912 ausgeführt wird, möglicherweise zurückladen. Der Garbage Collector 912 wählt bestimmte Stripes auf Blockebene für die Abfalldatensammlung auf Grundlage einer Anzahl von Faktoren aus, darunter zum Beispiel die Integrität der Blöcke in den Stripes auf Blockebene und wie viele der Daten in den Löschblöcken ungültig sind. In dem veranschaulichten Beispiel wird die Abfalldatensammlung an ganzen Stripes auf Blockebene ausgeführt, und der Flash-Verwaltungscode, der auf dem GPP 132 ausgeführt wird, protokolliert die Stripes auf Blockebene, die für ein Wiederverwenden in einer Auslagerungswarteschlange 904 bereit sind, was praktischerweise in dem zugehörigen Flash-Controllerspeicher 142 oder dem GPP-Speicher 134 umgesetzt werden kann.
• Die durch den GPP 132 oder den Flash-Controller 140 ausgeführten Flash-Verwaltungsfunktionen enthalten zusätzlich eine Auslagerungsfunktion 914, die die immer noch gültigen Daten auslagert, die in Stripes auf Blockebene gespeichert sind, die in die Auslagerungswarteschlange 904 gestellt sind. Zum Auslagern solcher Daten gibt die Auslagerungsfunktion 914 Schreibanforderungen an die Datenablagefunktion 910 aus, um anzufordern, dass die Daten des alten Stripe auf Blockebene in einen neuen Stripe auf Blockebene in dem NAND-Flashspeichersystem 150 geschrieben werden. Außerdem aktualisiert die Auslagerungsfunktion 914 die LPT-Tabelle 900, um die aktuelle Zuordnung zwischen den logischen und physischen Adressen der Daten zu entfernen. Sobald alle immer noch gültigen Daten aus dem alten Stripe auf Blockebene entfernt worden sind, wird der alte Stripe auf Blockebene an die Auflösefunktion für Stripes auf Blockebene 916 übergeben, die den alten Stripe auf Blockebene in seine Bestandteilblöcke zerlegt, wodurch die Zuordnung der Blöcke aufgehoben wird. Der Flash-Controller 140 löscht anschließend jeden der Blöcke, die vorher den aufgelösten Stripe auf Blockebene gebildet haben, und erhöht eine zugehörige Programm/Lösch- (P/E) Zyklusanzahl für den Block in P/E-Zykluszählern 944. Auf Grundlage der Integritätskennzahlen jedes gelöschten Blocks wird jeder gelöschte Block durch eine Block-Stilllegungsfunktion 918 von den auf dem GPP 132 ausgeführten Flash-Verwaltungsfunktionen entweder stillgelegt (d.h. wird nicht mehr zum Speichern von Benutzerdaten verwendet) oder alternativ zur Wiederverwendung vorbereitet, indem die Kennung des Blocks in eine entsprechende Ready-to-Use- (RTU) Warteschlange 906 in dem zugehörigen GPP-Speicher 134 gestellt wird.
• Wie ferner in 9 gezeigt, enthalten die auf dem GPP 132 ausgeführten Flash-Verwaltungsfunktionen eine Hintergrund-Integritätsprüfung 930. Die Hintergrund-Integritätsprüfung 930, die unabhängig von den Lese und -Schreibanforderungs-IOPs von Hosts wie beispielsweise Prozessorsystemen 102 arbeitet, bestimmt kontinuierlich eine oder mehrere Blockintegritätskennzahlen 942 für Blöcke, die zu Stripes auf Blockebene gehören, die in belegten Blockwarteschlangen 902 aufgezeichnet sind. Auf Grundlage der einen oder der mehreren Blockintegritätskennzahlen 942 kann die Hintergrund-Integritätsprüfung 930 Stripes auf Blockebene für eine Bearbeitung durch die Auslagerungsfunktion 914 in die Auslagerungswarteschlange 904 stellen.
• Unter folgender Bezugnahme auf 10 wird eine detailliertere Ansicht eines Flash-Controllers 140 gemäß einer Ausführungsform dargestellt. In dieser Ausführungsform ist der Flash-Controller 140 konfiguriert (z.B. in Hardware, Firmware, Software oder irgendeiner Kombination davon), um die Stilllegung von Speicher in den Flash-Speichermodulen M0a, M0b, M1a, M1b, ..., M1a und M15b eines NAND-Flashspeichersystems 150 zu unterstützen, zum Beispiel auf seitenweiser Grundlage statt auf blockweiser Grundlage oder einer Kombination davon. Der Flash-Controller 140 kann ferner konfiguriert werden, um eine physische Seite von Speicher stillzulegen, während eine oder mehrere andere physische Seiten aktiv gehalten werden, die eine allgemeine Gruppe von Speicherzellen mit mehreren Bits in der stillgelegten physischen Seite gemeinsam nutzen.
• In der veranschaulichten Ausführungsform enthält der Flash-Controller 140 einen Komprimierer 1000, der selektiv einen oder mehrere Datenkompressionsalgorithmen auf Daten anwendet, die in das zugehörige NAND-Flashspeichersystem 150 geschrieben sind, einen Dekomprimierer 1002, der die aus dem NAND-Flashspeichersystem 150 ausgelesenen komprimierten Daten dekomprimiert, und einen Datenverwürfler 1004. Der Flash-Controller 140 kann auch eine optionale Fingerabdruck-Engine 1006 enthalten, die der Fingerabdruck-Engine 118 im Schnittstellenknoten 122 ähnlich ist. Der Flash-Controller 140 verwendet den Datenverwürfler 1004, um ein vorbestimmtes Datenverwürfelungs- (d.h. Datenverschleierungs-) Muster auf Daten anzuwenden, die in den NAND-Flashspeicher150 geschrieben sind, um die Belastbarkeit zu verbessern und eine Zelle-zu-Zelle-Interferenz zu vermindern.
• Wie ferner in 10 veranschaulicht, enthält der Flash-Controller 140 einen Schreibcache 1010. Der Schreibcache 1010 enthält Speicherplatz für eine oder mehrere Cachezeilen 1012, um Schreibdaten in Erwartung eines Schreibens von Daten in das NAND-Flashspeichersystem 150 zu puffern. In der veranschaulichten Ausführungsform enthält jede Cachezeile 1012 mehrere (z.B. 16) Segmente 1014a bis 1014p, die jeweils Speicherplatz für einen jeweiligen Stripe auf Seitenebene für bis zu sechzehn Datenseiten bereitstellen (maximal fünfzehn Datenseiten und eine Datenschutzseite). Wie gezeigt, wird für eine einfachere Umsetzung bevorzugt, wenn der Flash-Controller 140 jede Seite gepuffert in ein vorgegebenes Segment 1014 der Cachezeile 1012 in den entsprechenden Chip-Index, Ebenenindex und physischen Seitenindex in jedem der sechzehn Flash-Speichermodule schreibt. Daher schreibt der Flash-Controller 140 die Datenseiten aus einem Segment 1014a in eine erste physische Seite (z.B. Seite23) in jedem der Flashspeichermodule M0a bis M15a, schreibt die Datenseiten aus einem Segment 1014b in eine zweite physische Seite in jedem der Flashspeichermodule M0a bis M15a, und schreibt die Datenseiten aus einem Segment 1014p auf sechzehn physische Seiten in jedem der Flashspeichermodule M0a bis M15a.
• Unter Bezugnahme auf 11A und 118 werden ein beispielhafter herkömmlicher Komprimierer 1100 und ein beispielhafter herkömmlicher Dekomprimierer 1150 in Form eines Blockschaubilds veranschaulicht, die jeweils eine adaptive Codierung umsetzen. Es sollte klar sein, dass in den Datenspeichersystemen, die gemäß der vorliegenden Offenbarung konfiguriert sind, der herkömmliche Komprimierer 1100 durch einen Komprimierer 1000 ersetzt wird, und ein herkömmlicher Dekomprimierer 1150 durch einen Dekomprimierer 1002 ersetzt wird. Der Komprimierer 1100 und der Dekomprimierer 1150 enthalten jeweils einen Prädiktor 1102, der alle vorhergehenden Symbole (y⁽¹⁾, y⁽²⁾, ..., y^(t-1)) überprüft und eine Gruppe von Vorhersagen Pr(y^(t)) in Bezug auf den Wert eines nächsten Symbols y^(t) erzeugt. Ein arithmetischer Codierer 1104 erzeugt einen Ausgabestrom auf Grundlage der Gruppe von Vorhersagen Pr(y^(t)) und empfangenen Eingabesymbolen, wobei jedes Eingabesymbol durch log[1/Pr(y^(t))] Bits dargestellt wird. Wenn Vorhersagen durch einen Prädiktor 1102 gut sind (d.h. wenn Pr(y^(t)) > 1/K, wobei „K“ die Anzahl von Symbolen in einem Alphabet ist), tritt eine Kompression in dem Ausgabestrom auf. Es sollte klar sein, das für eine präzise Umkehrung des Kompressionsprozesses die Gruppe von Vorhersagen Pr(y^(t)), die durch den Prädiktor 1102 des Dekomprimierers 1150 generiert werden, exakt dieselben sein müssen wie diejenigen, die durch den Prädiktor 1102 des Komprimierers 1100 generiert wurden. Die Ausgabe vom Prädiktor 1102 des Dekomprimierers 1150 wird als Eingabe für einen arithmetischen Codierer 1154 bereitgestellt, der einen komprimierten Eingabestrom decodiert, um auf Grundlage der Eingabe ein dekomprimiertes Symbol zu generieren.
• Unter Bezugnahme auf 12 wird ein beispielhafter herkömmlicher Prädiktor 1200 in Form eines Blockschaubilds veranschaulicht, der eine Vorhersage durch Kontextmischung ausführt. Der Prädiktor 1200 enthält eine Gesamtheit von „m“ verschiedenen Modellen, die jeweils Vorhersagen in Bezug auf einen Wert eines nächsten Symbols erzeugen, und eine Mischeinrichtung 1204, die die Vorhersagen von allen Modellen zu einer endgültigen Vorhersage kombiniert. Die Mischeinrichtung 1204 kann zum Beispiel einen Durchschnittswert der Modellvorhersagen wie folgt ermitteln: $$\text{Pr}\left({\text{y}}^{\left(\text{t}\right)}=\text{k}\right)=1/\text{m*}\left[{\text{p}}_1\left({\text{y}}^{\left(\text{t}\right)}=\text{k}\right)+{\text{p}}_2\left({\text{y}}^{\left(\text{t}\right)}=\text{k}\right)+\dots +{\text{p}}_{\text{m}}\left({\text{y}}^{\left(\text{t}\right)}=\text{k}\right)\right]$$

  
• Unter Bezugnahme auf 13, wird eine beispielhafte herkömmliche Mischeinrichtung 1300 in Form eines Blockschaubilds veranschaulicht, die ein logistisches Mischen ausführt. Logistisches Mischen entspricht einer logistischen Regression, wobei die Gewichtungen durch stochastischen Gradientenabfall optimiert werden. Logistisches Mischen wird jedoch nur für K = 2 definiert. Aus den Modellvorhersagen p_i = p_i(y^(t)) wird ein Merkmalsvektor x^(t) wie folgt berechnet: $$\begin{array}{c}{x}^{\left(t\right)}=\left[\text{strecken}\left(p_1\left(y^{\left(t\right)}\right)\right),\text{strecken}\left(p_2\left(y^{\left(t\right)}\right)\right),\dots ,\text{strecken}\left(p_m\left(y^{\left(t\right)}\right)\right)\right]\\ =\left[\frac{\text{log }{p}_1\left(y^{\left(t\right)}=1\right)}{\text{log }{p}_1\left(y^{\left(t\right)}=2\right)},\frac{\text{log }{p}_2\left(y^{\left(t\right)}=1\right)}{\text{log }{p}_2\left(y^{\left(t\right)}=2\right)},\dots ,\frac{\text{log }{p}_m\left(y^{\left(t\right)}=1\right)}{\text{log }{p}_m\left(y^{\left(t\right)}=2\right)}\right]\in {ℝ}^m\end{array}$$

  
• Bei einem vorgegebenen Gewichtungsvektor ϑ = (ϑ₁, ϑ₂, ..., ϑ_m) kann eine endgültige Vorhersage wie folgt berechnet werden: $$\text{Pr}\left(y^{\left(t\right)}=1\right)=\text{stauchen}\left({\displaystyle \sum _{i=1}^m{\theta }_i{x}_i^{\left(t\right)}}\right)={\left(1+\text{exp}\left[-{\displaystyle \sum _{i=1}^m{\theta }_i{x}_i^{\left(t\right)}}\right]\right)}^{-1}$$

  

  $$\text{Pr}\left(y^{\left(t\right)}=2\right)=1-\text{Pr}\left(y^{\left(t\right)}=1\right)$$

  
• Wie bekannt ist, ist die Stauchfunktion eine allgemeine logistische Funktion, die in neuralen Netzwerken verwendet wird. Der Gewichtungsfaktor kann anschließend zum Beispiel unter Verwendung eines stochastischen Gradientenabfalls (SGD) angepasst werden, um die Kompression wie folgt zu maximieren: $${\theta }_i:{\theta }_i+\alpha \left(y^{\left(t-1\right)}-\text{Pr}\left(y^{\left(t-1\right)}=1\right)\right)x_i^{\left(t-1\right)}$$

  

  wobei α ein Größenparameter für einen Gradientabstiegsschritt ist.
• Verschiedene Ausführungsformen der vorliegenden Offenbarung beziehen sich auf einen Komprimierer/Dekomprimierer für eine nicht binäre Maximalentropie-Kontextmischung, der einen arithmetischen Codierer/Decodierer enthält, der anhand von Symbolen arbeitet, die zu einem Alphabet der Größe K > 2 gehören. Gemäß einer oder mehreren Ausführungsformen enthält der Komprimierer/Dekomprimierer eine Kontextmodellgesamtheit (d.h. eine Mehrzahl von Kontextmodellen), die Vorhersagen in Bezug auf einen Wert eines nächsten Symbols erzeugt, das encodiert werden soll, und eine Mischeinrichtung, die eine Feature-Matrix x^(t) aus den Kontextmodellvorhersagen erstellt und einen Maximalentropie-Klassifizierer schult (z.B. unter Verwendung eines stochastischen Gradientenabfalls (SGD)), der eine endgültige Vorhersage erzeugt. Die endgültige Vorhersage von der Mischeinrichtung wird als Eingabe für den arithmetischen Codierer/Decodierer bereitgestellt. Es sollte klar sein, dass verschiedene Ausführungsformen umgesetzt werden können, indem eine unterschiedliche Anzahl von Einschränkungen für den Maximalentropie-Klassifizierer vorgegeben wird (was zu einer unterschiedlichen Anzahl von Mischgewichtungen führt). Es sollte klar sein, dass andere Schulungstechniken als SGD zum Schulen des Klassifizierers verwendet werden können (z.B. können Minibatch-Gradientenabfall oder Noise-Contrastive Estimation zum Schulen des Klassifizierers verwendet werden). Im Allgemeinen ist die einzige Einschränkung, dass die Gewichtungen, die zum Bilden einer Voraussage Pr(y^(t) | x^(t)) in dem Komprimierer verwendet werden, unter Verwendung einer Kenntnis von Symbolen y⁽¹⁾,...y^(t-1) geschult werden, sodass die exakt selbe Schulung in dem Dekomprimierer erfolgen kann. Zum Beispiel kann ein neurales Netzwerk durch Verketten von Maximalentropie-Mischeinrichtungen in mehreren Ebenen aufgebaut werden.
• Gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung wird ein Komprimierer/Dekomprimierer für eine nicht binäre Maximalentropie-Kontextmischung offenbart, der die Streckfunktion für allgemeines K > 2 wie folgt neu definiert: $${\text{strecken}}_K\left(p_i\right)=\left(\frac{\text{log }{p}_i\left(y^{\left(t\right)}=1\right)}{\text{log }{p}_i\left(y^{\left(t\right)}=K\right)},\frac{\text{log }{p}_i\left(y^{\left(t\right)}=2\right)}{\text{log }{p}_i\left(y^{\left(t\right)}=K\right)},\dots ,\frac{\text{log }{p}_i\left(y^{\left(t\right)}=K-1\right)}{\text{log }{p}_i\left(y^{\left(t\right)}=K\right)}\right)\in {ℝ}^{K-1}$$

  
• Es sollte klar sein, dass ein zugrundeliegender Gedanke ist, redundante Informationen zu entfernen, die von den Modellen stammen (da die Wahrscheinlichkeiten aller Symbole in der Summe 1 ergeben sollten). Es sollte ebenfalls klar sein, dass nicht notwendigerweise durch das Symbol „K“ geteilt werden muss, d.h. ein Teilen durch ein beliebiges Symbol funktioniert, solange das Symbol festgelegt ist.
• Anschließend wird die verallgemeinerte Feature-Matrix x^(t) angegeben durch: $$x^{\left(t\right)}=\left(\begin{array}{c}{\text{strecken}}_K\left(p_1\left(y^{\left(t\right)}\right)\right)\\ {\text{strecken}}_K\left(p_2\left(y^{\left(t\right)}\right)\right)\\ ⋮\\ {\text{strecken}}_K\left(p_m\left(y^{\left(t\right)}\right)\right)\end{array}\right)=\left(\begin{array}{llll}\frac{\text{log }{p}_1\left(y^{\left(t\right)}=1\right)}{\text{log }{p}_1\left(y^{\left(t\right)}=K\right)}\hfill & \frac{\text{log }{p}_1\left(y^{\left(t\right)}=2\right)}{\text{log }{p}_1\left(y^{\left(t\right)}=K\right)}\hfill & \cdots \hfill & \frac{\text{log }{p}_1\left(y^{\left(t\right)}=K-1\right)}{\text{log }{p}_1\left(y^{\left(t\right)}=K\right)}\hfill \\ \frac{\text{log }{p}_2\left(y^{\left(t\right)}=1\right)}{\text{log }{p}_2\left(y^{\left(t\right)}=K\right)}\hfill & \frac{\text{log }{p}_2\left(y^{\left(t\right)}=2\right)}{\text{log }{p}_2\left(y^{\left(t\right)}=K\right)}\hfill & \cdots \hfill & \frac{\text{log }{p}_2\left(y^{\left(t\right)}=K-1\right)}{\text{log }{p}_2\left(y^{\left(t\right)}=K\right)}\hfill \\ ⋮\hfill & ⋮\hfill & \ddots \hfill & ⋮\hfill \\ \frac{\text{log }{p}_m\left(y^{\left(t\right)}=1\right)}{\text{log }{p}_m\left(y^{\left(t\right)}=K\right)}\hfill & \frac{\text{log }{p}_m\left(y^{\left(t\right)}=2\right)}{\text{log }{p}_m\left(y^{\left(t\right)}=K\right)}\hfill & \cdots \hfill & \frac{\text{log }{p}_m\left(y^{\left(t\right)}=K-1\right)}{\text{log }{p}_m\left(y^{\left(t\right)}=K\right)}\hfill \end{array}\right){\in }^{ℝm\times \left(K-1\right)}$$

  
• Gemäß einer oder mehreren Ausführungsformen kann eine Maximalentropie-Mischeinrichtung die folgende Form annehmen: $$\text{Pr}\left(t^{\left(t\right)}=k|x^{\left(t\right)}\right)=\{\begin{array}{lll}\frac{1}{Z}\text{exp}\left[f_{\theta }\left(k,x^{\left(t\right)}\right)\right]\hfill & \text{wenn}\hfill & k=\mathrm{1,2,}\dots K-1\hfill \\ \frac{1}{Z}\hfill & \text{sonst}\hfill & \hfill \end{array}$$

  

  wobei f_θ(k,x^(t)) eine lineare Kombination der Einträge der Feature-Matrix ist und Z ein Skalar ist, auf den als die normalisierende Konstante Bezug genommen wird.
• Unter Bezugnahme auf 14, wird der Komprimierer 1000 von 10 mit zusätzlichen Details veranschaulicht. Wie veranschaulicht, enthält der Komprimierer 1000 eine Anzahl von Kontextmodellen (von denen nur acht in 14 gezeigt sind), deren Ausgaben für Eingaben in eine Mischeinrichtung 1400 des neuralen Netzwerks bereitgestellt werden. Eine erlernte Vorhersage wird von der Mischeinrichtung 1400 für einen arithmetischen Codierer 1402 bereitgestellt, um ein Generieren von komprimierten Daten aus den Eingabesymbolen zu ermöglichen.
• Unter Bezugnahme auf 15 veranschaulicht eine Tabelle 1500 Gleichungen für drei verschiedene Ausführungsformen, d.h. die Ausführungsformen „A“, „B“ und „C“, die eine Entropie unter leicht unterschiedlichen Einschränkungen gemäß der vorliegenden Offenbarung maximieren. Der Prädiktor in der Ausführungsform „C“ hat dieselbe funktionale Form wie der von Mattern abgeleitete Prädiktor (siehe Mattern, C., „Mixing Strategies in Data Compression" in Data Compression Conference (DCC), 2012, Seite 337 bis 346). Der Mattern-Prädiktor erforderte jedoch, dass Gewichtungen θ_i nicht null sind und in der Summe eins ergeben. Die offenbarte Maximalentropie-Mischeinrichtung erfordert jedoch nicht, dass die Gewichtungen θ_i nicht null sind und in der Summe eins ergeben. Die Ausführungsform „A“ verlangt die wenigsten Einschränkungen und führt somit zur größten Anzahl von Mischgewichtungen. Die Ausführungsform „A“ sollte immer das höchste Kompressionsverhältnis bereitstellen, da alle von den Modellen bereitgestellten Informationen zum Bilden der endgültigen Vorhersage verwendet werden. Insbesondere kann die Ausführungsform „A“ ein höheres Kompressionsverhältnis erzielen als der durch Mattern definierte Komprimierer in dem vorgenannten Verweis.
• Unter Bezugnahme auf 16 wird die Mischeinrichtung 1400 als eine Maximalentropie-Mischeinrichtung für die Ausführungsform „A“ mit K = 4 umgesetzt. Insgesamt sind 3*3*m = 9*m Gewichtungen vorhanden, die wie folgt erlernt werden müssen: $$\begin{array}{c}\begin{array}{cc}{\theta }^{\left(1\right)}=\left(\begin{array}{lll}{\theta }_{\mathrm{1,1}}^{\left(1\right)}\hfill & {\theta }_{\mathrm{1,2}}^{\left(1\right)}\hfill & {\theta }_{\mathrm{1,3}}^{\left(1\right)}\hfill \\ {\theta }_{\mathrm{2,1}}^{\left(1\right)}\hfill & {\theta }_{\mathrm{2,2}}^{\left(1\right)}\hfill & {\theta }_{\mathrm{2,3}}^{\left(1\right)}\hfill \\ ⋮\hfill & ⋮\hfill & ⋮\hfill \\ {\theta }_{m\mathrm{,1}}^{\left(1\right)}\hfill & {\theta }_{m\mathrm{,2}}^{\left(1\right)}\hfill & {\theta }_{m\mathrm{,3}}^{\left(1\right)}\hfill \end{array}\right)\in {ℝ}^{m\times 3}& {\theta }^{\left(2\right)}=\left(\begin{array}{lll}{\theta }_{\mathrm{1,1}}^{\left(2\right)}\hfill & {\theta }_{\mathrm{1,2}}^{\left(2\right)}\hfill & {\theta }_{\mathrm{1,3}}^{\left(2\right)}\hfill \\ {\theta }_{\mathrm{2,1}}^{\left(2\right)}\hfill & {\theta }_{\mathrm{2,2}}^{\left(2\right)}\hfill & {\theta }_{\mathrm{2,3}}^{\left(2\right)}\hfill \\ ⋮\hfill & ⋮\hfill & ⋮\hfill \\ {\theta }_{m\mathrm{,1}}^{\left(2\right)}\hfill & {\theta }_{m\mathrm{,2}}^{\left(2\right)}\hfill & {\theta }_{m\mathrm{,3}}^{\left(2\right)}\hfill \end{array}\right)\in {ℝ}^{m\times 3}\end{array}\\ {\theta }^{\left(3\right)}=\left(\begin{array}{lll}{\theta }_{\mathrm{1,1}}^{\left(3\right)}\hfill & {\theta }_{\mathrm{1,2}}^{\left(3\right)}\hfill & {\theta }_{\mathrm{1,3}}^{\left(3\right)}\hfill \\ {\theta }_{\mathrm{2,1}}^{\left(3\right)}\hfill & {\theta }_{\mathrm{2,2}}^{\left(3\right)}\hfill & {\theta }_{\mathrm{2,3}}^{\left(3\right)}\hfill \\ ⋮\hfill & ⋮\hfill & ⋮\hfill \\ {\theta }_{m\mathrm{,1}}^{\left(3\right)}\hfill & {\theta }_{m\mathrm{,2}}^{\left(3\right)}\hfill & {\theta }_{m\mathrm{,3}}^{\left(3\right)}\hfill \end{array}\right)\in {ℝ}^{m\times 3}\end{array}$$

  
• Wie veranschaulicht, enthält die Mischeinrichtung 1400 einen Feature-Matrix-Berechnungsblock, der eine Feature-Matrix x^(t) berechnet, „K - 1“ Skalarproduktblöcke, die Skalarprodukte der Feature-Matrix-Elemente und zugehörigen Gewichtungen berechnen, „K-1“ natürliche Exponentialfunktions- (Exp) Blöcke, die das e^(Skalarprodukt) für Skalarproduktergebnisse berechnen, und einen Berechnungsblock Z, der eine normalisierende Konstante berechnet und anschließend erlernte Vorhersagen (Pr(y^(t)) erzeugt. Während einer Simulation mit einem Dataset von 256 x 1 MB Beispielen für K = 2 (d.h. 1-Bit-Symbolen) wurde ein Kompressionsverhältnis (CR) von 8,04 mit einem Durchsatz von 1,38 MB/s für einen Prozessor mit einem Kern unter Verwendung einer herkömmlichen Komprimierung von binärer Kontextmischung erzielt. Ein CR von 8,11 mit einem Durchsatz von 2,11 MB/s wurde während einer Simulation für die Ausführungsform „C“ mit K = 4 (d.h. 2-Bit-Symbolen) für das Dataset erzielt, was einer um ungefähr dreiundfünfzig Prozent schnelleren Komprimierung im Vergleich mit dem Fall einer herkömmlichen Komprimierung von binärer Kontextmischung (d.h. K = 2) entspricht. Ein CR von 8,21 mit einem Durchsatz von 1,63 MB/s wurde während einer Simulation für die Ausführungsform „A“ mit K = 4 für das Dataset erzielt, was einem um ungefähr zwei Prozent höheren CR im Vergleich mit einer herkömmlichen Komprimierung von binärer Kontextmischung entspricht.
• Unter Bezugnahme auf 17 wird ein beispielhafter Prozess 1700 veranschaulicht, der eine Kompression für ein Datenspeichersystem an Datenseiten gemäß einer Ausführungsform der vorliegenden Offenbarung ausführt. In einer oder mehreren Ausführungsformen wird der Prozess 1700 im Block 1701 durch den Komprimierer 1000 des Flash-Controllers 140 initiiert, wenn eine Schreib-IOP (z.B. eine 4-kB-Datenseite mit einer Anzahl von Symbolen) empfangen wird. In einer weiteren Ausführungsform kann der Prozess 1700 auch durch den Komprimierer 1000 des Flash-Controllers 140 in Reaktion auf eine Anforderung einer Kompression im Hintergrund initiiert werden. Als Nächstes bestimmt der Flash-Controller 140 im Entscheidungsblock 1702, ob die IOP mit einer Anforderung, eine Datenseite in eine Flash-Karte 126 zu schreiben (d.h. einer Schreib-IOP) oder einer Anforderung von einer Kompression im Hintergrund entspricht. In Reaktion darauf, dass die empfangene IOP weder einer Schreibanforderung für eine Datenseite noch einer Anforderung von einer Kompression im Hintergrund entspricht, geht die Steuerung von Block 1702 zu Block 1714 über, an dem der Prozess 1700 endet. In Reaktion darauf, dass die empfangene IOP einer Schreibanforderung für eine Datenseite oder einer Anforderung von einer Kompression im Hintergrund entspricht, geht die Steuerung zu Block 1704 über. Im Block 1704 generiert der Komprimierer 1000 Modellvorhersagen in Bezug auf einen Wert eines nächsten Symbols einer Datenseite, das encodiert werden soll. Als Nächstes generiert der Komprimierer 1000 im Block 1706 eine Gruppe von endgültigen Vorhersagen aus den Modellvorhersagen. Danach generiert der Komprimierer 1000 im Block 1708 komprimierte Daten auf Grundlage von empfangenen Eingabesymbolen und die Gruppe von endgültigen Vorhersagen. Als Nächstes aktualisiert der Komprimierer 1000 im Block 1710 Modellstatistiken und passt Mischgewichtungen an. Danach bestimmt der Komprimierer 1000 im Block 1712, ob die Datenseite ein weiteres Symbol enthält, für das eine Kompression erforderlich ist. In Reaktion darauf, dass die Datenseite ein weiteres Symbol enthält, für das eine Kompression erforderlich ist, geht die Steuerung von Block 1712 zu Block 1704 über. In Reaktion darauf, dass die Datenseite kein weiteres Symbol enthält, für das eine Kompression erforderlich ist, geht die Steuerung von Block 1712 zu Block 1714 über, an dem der Prozess 1700 endet.
• Unter Bezugnahme auf 18 wird ein beispielhafter Prozess 1800 veranschaulicht, der eine Dekompression für ein Datenspeichersystem an Datenseiten gemäß einer Ausführungsform der vorliegenden Offenbarung ausführt. In einer oder mehreren Ausführungsformen wird der Prozess 1800 im Block 1801 durch den Dekomprimierer 1002 des Flash-Controllers 140 initiiert, wenn eine Lese-IOP empfangen wird. In einer weiteren Ausführungsform kann der Prozess 1800 auch durch den Dekomprimierer 1002 des Flash-Controllers 140 in Reaktion auf eine Anforderung einer Dekompression im Hintergrund initiiert werden. Als Nächstes bestimmt der Flash-Controller 140 im Entscheidungsblock 1802, ob die IOP einer Anforderung, eine Datenseite aus einer Flash-Karte 126 auszulesen (d.h. einer Lese-IOP) oder einer Anforderung von einer Dekompression im Hintergrund entspricht. In Reaktion darauf, dass die empfangene IOP weder einer Leseanforderung für eine Datenseite noch einer Anforderung einer Dekompression im Hintergrund entspricht, geht die Steuerung von Block 1802 zu Block 1814 über, an dem der Prozess 1800 endet. In Reaktion darauf, dass die empfangene IOP einer Leseanforderung für eine Datenseite oder einer Anforderung einer Dekompression im Hintergrund entspricht, geht die Steuerung zu Block 1804 über. Im Block 1804 generiert der Dekomprimierer 1002 Modellvorhersagen in Bezug auf einen Wert eines nächsten Symbols, das für die Datenseite decodiert werden soll. Als Nächstes generiert der Dekomprimierer 1002 im Block 1806 eine Gruppe von endgültigen Vorhersagen aus den Modellvorhersagen. Danach generiert der Dekomprimierer 1002 im Block 1808 die empfangenen Eingabesymbole auf Grundlage der komprimierten Daten und der Gruppe von endgültigen Vorhersagen. Als Nächstes aktualisiert der Dekomprimierer 1002 im Block 1810 Modellstatistiken und passt Mischgewichtungen an. Danach bestimmt der Dekomprimierer 1002 im Block 1812, ob für ein weiteres Symbol in der Datenseite eine Dekompression erforderlich ist. In Reaktion darauf, dass für ein weiteres Symbol in der Datenseite eine Dekompression erforderlich ist, geht die Steuerung von Block 1812 zu Block 1804 über. In Reaktion darauf, dass kein weiteres Symbol in der Datenseite eine Dekompression erfordert, geht die Steuerung von Block 1812 zu Block 1814 über, an dem der Prozess 1800 endet.
• Im Allgemeinen mischen spätere PAQ-Versionen (z.B. PAQ8 und später) Vorhersagen aus über fünfhundert verschiedenen Kontextmodellen, um ein relative hohes Kompressionsverhältnis zu erzielen. Leider hat der PAQ8-Algorithmus eine sehr langsame Geschwindigkeit, was zumindest teilweise auf die große Anzahl von verwendeten Kontextmodellen zurückzuführen ist. Im Allgemeinen ist die Gesamtheit von Kontextmodellen, die in PAQ8 verwendet werden, so ausgelegt, dass eine hohe Kompression für viele verschiedene Datentypen bereitgestellt wird, und viele spezielle Kontextmodelle enthält, die für eine umfangreiche Vielfalt von Datentypen ausgelegt ist, z.B. Bilder, Audio, Text usw.
• Für eine Vorhersage zu einem Datensymbol y^(t) berechnet jedes Kontextmodell zuerst einen P-Bit-Kontext auf Grundlage von Datensymbolen, die das Kontextmodell vorher gesehen hat, d.h. Symbole y⁽¹⁾, y⁽²⁾,..., y^(t-1). Zwei beispielhafte Kontextfunktionen sind wie folgt: $$\begin{array}{l}{\text{CXT}}_1\left(y^{\left(1\right)},y^{\left(2\right)},\dots ,y^{\left(t-1\right)}\right)=\text{hash}\left[y^{\left(t-4\right)},y^{\left(t-3\right)},y^{\left(t-2\right)},y^{\left(t-1\right)}\right]\in \left[{\mathrm{0,2}}^{\text{P}}-1\right]\\ {\text{CXT}}_2\left(y^{\left(1\right)},y^{\left(2\right)},\dots ,y^{\left(t-1\right)}\right)=\text{hash}\left[y^{\left(t-7\right)},y^{\left(t-5\right)},y^{\left(t-3\right)},y^{\left(t-1\right)}\right]\in \left[{\mathrm{0,2}}^{\text{P}}-1\right]\end{array}$$

  
• Wie oben veranschaulicht, führen beide CXT₁ - und CXT₂ -Kontextfunktionen Hash-Funktionen an bestimmten Symbolen aus.
• In einer typischen Umsetzung zeigt der P-Bit-Kontext (CXT) auf eine Adresse im Speicher, wo eine Gruppe von „K“ Zählern, d.h. N₁(CXT), N₂(CXT), ..., N_k(CXT) abgerufen werden kann. N_k(CXT) zählt, wie oft das k-te Symbol in dem Kontext beobachtet worden ist. Die Vorhersagen zum Datensymbol y^(t) können anschließend wie folgt berechnet werden: $$\text{Pr}\left(y^{\left(t\right)}=k|CXT\left(y^{\left(1\right)},y^{\left(2\right)},\dots ,y^{\left(t-1\right)}\right)\right)=\frac{N_k\left(CXT\right)}{{\displaystyle \sum _{k\text{'}=1}^K{N}_{k\text{'}}}\left(CXT\right)}$$

  
• Gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung wird die Tatsache berücksichtigt, dass Kundenarbeitslasten üblicherweise aus bestimmten Arten von Daten bestehen (z.B. formatierte Datenbank-Datensätze), um eine Anpassung von Kontextmodell-Gesamtheiten zum Beschleunigen von Kompression/Dekompression zu ermöglichen. Gemäß einer Ausführungsform der vorliegenden Offenbarung wird eine iterative Technik zum Entwickeln relativ kleiner Kontextmodell-Gesamtheiten umgesetzt. Die iterative Technik reduziert eine große Gruppe von M Kontextmodellen auf eine Untergruppe von M' erwünschten Kontextmodellen (wobei M' < M) unter Beibehaltung eines relativ hohen Kompressionsverhältnisses (CR). Die Techniken zum Reduzieren einer Größe einer Kontextmodell-Gesamtheit kann offline umgesetzt werden oder als ein Hintergrundprozess ausgeführt werden (z.B. in Firmware), um die Gesamtheit von Kontextmodellen, die in einem Komprimierer/Dekomprimierer für eine Kontextmischung verwendet werden, an verschiedene und sich ändernde Kundenarbeitslasten anzupassen.
• In einem Beispiel kann ein iterativer Prozess für eine Kontextmodellauswahl für einen Komprimierer mit einer Gruppe von „N“ nicht ausgewählten Modellen und „0“ ausgewählten Modellen beginnen. Der Komprimierer wird zunächst „N“ mal ausgeführt, wobei jedes Mal eines der möglichen Modelle aktiviert und bestimmt wird, welches Modell das beste Kompressionsverhältnis (CR) erzeugt. Das Kontextmodell, das das beste CR erzeugt, wird anschließend in die Kontextmodell-Gesamtheit oder -Gruppe aufgenommen. Nach einem „N“-maligen Ausführen des Komprimierers ist eine Gruppe von „N - 1“ nicht ausgewählten Kontextmodellen und ein ausgewähltes Kontextmodell vorhanden. Der Komprimierer wird danach für die übrigen „N - 1“ Kontextmodelle ausgeführt, und eine Bestimmung wird in Bezug darauf getroffen, welches Kontextmodell (in den übrigen „N - 1“ Kontextmodellen) nach dem Hinzufügen zu der Gruppe von ausgewählten Kontextmodellen das höchste CR erzeugt. Das Modell wird dann der Gruppe hinzugefügt. Der Prozess wird wiederholt, bis die gewünschte Anzahl von Modellen gefunden ist. Der Prozess kann zum Beispiel in einem Flash-System als ein Hintergrundprozess ausgeführt werden, der die ausgewählten Kontextmodelle für eine Kundenarbeitslast anpasst. Zum Beispiel hat PAQ8I in einer Simulation, die ein Dataset mit 8 x 1 MB Beispielen verwendet, 552 Kontextmodelle mit einem CR von 9,00 und einem Durchsatz von 0,02 MB/s implementiert. Im Gegensatz dazu führte die Umsetzung des offenbarten Kontextmodell-Reduzierungsprozesses, der hierin für das Dataset mit 8 Kontextmodellen beschrieben wurde, zu einem CR von 8,36 mit einem Durchsatz von 2,11 MB/s. Es sollte klar sein, dass eine Reduzierung der Größe der Kontextmodell-Gesamtheit von 522 auf 6 den Durchsatz drastisch erhöht, während das CR nur unwesentlich verringert wird.
• Unter Bezugnahme auf 19 wird ein beispielhafter Prozess 1900 veranschaulicht, der eine reduzierte Kontextmodell-Gesamtheit, die zur Datenkompression/-dekompression in einem Datenspeichersystem verwendet werden soll, auf Grundlage einer Kundenarbeitslast gemäß einer Ausführungsform der vorliegenden Offenbarung bestimmt. Der Prozess 1900 kann zum Beispiel durch einen Flash-Controller 140 umgesetzt werden. Der Prozess 1900 kann durch den Flash-Controller 140 periodisch im Block 1901 als Hintergrundprozess initiiert werden. Als Nächstes bestimmt der Flash-Controller 140 im Entscheidungsblock 1902, ob ein reduziertes Kontextmodell angegeben ist, z.B. ob eine neue Kundenarbeitslast initiiert worden ist. In Reaktion darauf, dass im Block 1902 kein reduziertes Kontextmodell angegeben ist, geht die Steuerung zu Block 1924 über, an dem der Prozess 1900 endet. In Reaktion darauf, dass im Block 1902 ein reduziertes Kontextmodell angegeben ist, geht die Steuerung zu Block 1904 über, in dem der Flash-Controller 140 eine Gruppe S initiiert (die eine Gesamtheit von Kontextmodellen darstellt).
• Als Nächstes setzt der Flash-Controller 140 die Variable „N“ im Block 1906 auf Null. Es sollte klar sein, dass „N“ das aktuelle Kontextmodell darstellt. Zum Beispiel wird für „N“ gleich Null ein „Kontextmodell 0“ angegeben. Als weiteres Beispiel wird für „N“ gleich einhundert ein „Kontextmodell 100“ angegeben. Als noch weiteres Beispiel wird für „N“ gleich fünfhundert ein „Kontextmodell 500“ angegeben. Anschließend bestimmt der Flash-Controller 140 im Entscheidungsblock 1908, ob sich das Kontextmodell N bereits in der Gruppe S befindet. Da die Gruppe S im Block 1904 initialisiert wurde, ist die Gruppe S leer und die Steuerung geht zunächst von Block 1908 zu Block 1914 über, wo das Kontextmodell N (d.h. Kontextmodell 0) zur Gruppe S' hinzugefügt wird. Als Nächstes misst der Flash-Controller 140 im Block 1916 das Kompressionsverhältnis (CR) und zeichnet es auf Schulungsdaten (die ein repräsentatives Beispiel für eine Kundenarbeitslast sind) unter Verwendung der Gruppe S' auf. Anschließend erhöht der Flash-Controller 140 im Block 1910 „N“ um eins (d.h. N = N + 1).
• Als Nächstes bestimmt der Flash-Controller 140 im Entscheidungsblock 1912, ob „N“ gleich „M“ ist (wobei „M“ der Gesamtanzahl von Kontextmodellen entspricht, die in einer nicht reduzierten Kontextmodell-Gesamtheit sind). In Reaktion darauf, dass „N“ nicht gleich „M“ ist, kehrt die Steuerung in Block 1912 zum Block 1908 zurück, in dem der Flash-Controller 140 bestimmt, ob sich das Kontextmodell „N + 1“ in der Gruppe S befindet. Da der Prozess 1900 initialisiert worden ist, befindet sich das Kontextmodell „N + 1“ nicht in der Gruppe S, und die Steuerung geht vom Block 1908 zum Block 1914, zum Block 1916, zum Block 1910 und zum Block 1912 über. In Reaktion darauf, dass „N“ schließlich gleich „M“ ist, geht die Steuerung im Block 1912 zum Block 1918 über. Im Block 1918 identifiziert der Flash-Controller 140 das „N“ (d.h. das Kontextmodell N), das zu der größten Erhöhung des CR in der Gruppe S' geführt hat, und fügt das Kontextmodell N, das zu der größten Erhöhung des CR geführt hat, zu der Gruppe S hinzu.
• Von Block 1918 geht die Steuerung zum Entscheidungsblock 1920 über. Im Block 1920 bestimmt der Flash-Controller 140, ob eine gewünschte Größe einer reduzierten Kontextmodell-Gesamtheit erreicht worden ist (d.h. ob genug Kontextmodelle zu der Gruppe S hinzugefügt worden sind). Zum Beispiel kann die gewünschte Größe der reduzierten Kontextmodell-Gesamtheit auf Grundlage eines Erreichens eines gewünschten Mindest-CR und Durchsatzes bestimmt werden. In Reaktion darauf, dass die gewünschte Größe der reduzierten Kontextmodell-Gesamtheit nicht erreicht worden ist, geht die Steuerung im Block 1920 für eine weitere Wiederholung zum Block 1906 über, um ein weiteres Kontextmodell zu der Gruppe S hinzuzufügen. In Reaktion darauf, dass die gewünschte Größe der reduzierten Kontextmodell-Gesamtheit erreicht worden ist, geht die Steuerung im Block 1920 zum Block 1924 über, wo der Prozess 1900 endet.
• Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) enthalten, auf dem durch einen Computer lesbare Programmanweisungen gespeichert sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
• Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch eine Einheit zur Ausführung von Anweisungen beibehalten und speichern kann. Das durch einen Computer lesbare Speichermedium kann zum Beispiel eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiter-Speichereinheit oder jede geeignete Kombination aus dem Vorgenannten sein, es ist aber nicht darauf beschränkt. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flashspeicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer CD-ROM, eine DVD, ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination des Vorgenannten. Ein durch einen Computer lesbares Speichermedium soll, wie hierin verwendet, nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder andere Übertragungsmedien ausbreiten (z.B. durch ein Glasfaserkabel geleitete Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
• Hierin beschriebene durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
• Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben sind, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In dem letzteren Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch jeden Typ von Netzwerk verbunden werden, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, feldprogrammierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
• Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Veranschaulichungen von Ablaufplänen und/oder Blockschaubildern von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es sollte klar sein, dass jeder Block der Ablaufplandarstellungen und/oder der Blockschaubilder und Kombinationen von Blöcken in den Ablaufplandarstellungen und/oder den Blockschaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
• Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die über den Prozessor des Computers bzw. eine andere programmierbare Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegebenen Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, sodass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, die Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaubilder angegebenen Funktion/Schritts umsetzen.
• Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Arbeitsschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen durch einen Computer umgesetzten Prozess zu erzeugen, sodass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegebenen Funktionen/Schritte umsetzen.
• Die Ablaufpläne und Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder den Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zum Umsetzen der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Umsetzungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt auftreten. Zum Beispiel können zwei nacheinander gezeigte Blöcke tatsächlich im Wesentlichen parallel ausgeführt werden, oder die Blöcke können manchmal in der umgekehrten Reihenfolge ausgeführt werden, was von der beteiligten Funktionalität abhängt. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufplandarstellungen sowie Kombinationen von Blöcken in den Blockschaubildern und/oder der Ablaufplandarstellung durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die angegebenen Funktionen oder Handlungen durchführen oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
• Wie beschrieben wurde, legt ein Controller eines nicht flüchtigen Speicherarrays physische Seiten in dem nicht flüchtigen Speicherarray auf seitenweiser Grundlage still. Die vom Controller stillgelegten physischen Seiten enthalten eine erste physische Seite, die eine allgemeine Gruppe von Speicherzellen gemeinsam mit einer zweiten physischen Seite nutzt. Obwohl die erste physische Seite stillgelegt ist, behält der Controller die zweite physische Seite als eine aktive physische Seite bei, schreibt Dummy-Daten in die erste physische Seite, und schreibt von einem Host empfangene Daten in die zweite physische Seite.
• Die Erfindung wurde zwar insbesondere unter Bezugnahme auf eine oder mehrere bevorzugte Ausführungsformen gezeigt und beschrieben, doch wird einem Fachmann klar sein, dass verschiedene Änderungen in Form und Detail daran vorgenommen werden können, ohne von dem Erfindungsgedanken und dem Schutzumfang der Erfindung abzuweichen. Obwohl Aspekte in Bezug auf ein Datenspeichersystem mit einem Flash-Controller beschrieben worden sind, der bestimmte Funktionen steuert, sollte klar sein, dass die vorliegende Erfindung alternativ als Programmprodukt mit einer computerlesbaren Speichereinheit umgesetzt werden kann, die Programmcode speichert, der von einem Prozessor verarbeitet werden kann, um derartige Funktionen auszuführen oder zu veranlassen, dass derartige Funktionen ausgeführt werden. Wie hierin verwendet, ist eine „Speichereinheit“ insbesondere definiert, nur vorgeschriebene Herstellungsartikel aufzunehmen und Übertragungsmedien perse, transitorische Ausbreitungssignale per se und Formen von Energie perse auszuschließen.
• Obwohl Ausführungsformen beschrieben worden sind, die die Verwendung eines NAND-Flashspeichers enthalten, sollte außerdem klar sein, dass Ausführungsformen der vorliegenden Erfindung auch mit anderen Typen von nicht flüchtigem Direktzugriffspeicher (NVRAM) verwendet werden können, einschließlich zum Beispiel Phasenwechselspeicher (PCM) und Kombinationen davon.
• Die oben beschriebenen Figuren und die folgende schriftliche Beschreibung von bestimmten Strukturen und Funktion werden nicht zur Einschränkung des Schutzumfangs dessen, was die Anmelder erfunden haben, oder des Schutzumfangs der Ansprüche im Anhang vorgelegt. Die Figuren und die schriftliche Beschreibung werden stattdessen bereitgestellt, um jeden Fachmann zu lehren, die Erfindungen umzusetzen und zu verwenden, für die Patentschutz beantragt wird. Dem Fachmann wird klar sein, dass aus Gründen der Klarheit und zum besseren Verständnis nicht alle Merkmale einer gewerblichen Ausführungsform der Erfindungen beschrieben oder gezeigt worden sind. Dem Fachmann wird ebenfalls klar sein, dass die Entwicklung einer derzeitigen gewerblichen Ausführungsform, die Aspekte der vorliegenden Erfindungen integriert, zahlreiche umsetzungsspezifische Entscheidungen erfordern wird, um das letztendliche Ziel des Entwicklers für die gewerbliche Ausführungsform zu erreichen. Derartige umsetzungsspezifische Entscheidungen können die Einhaltung von systembezogenen, geschäftsbezogenen, behördenbezogenen und anderen Einschränkungen enthalten und sind wahrscheinlich nicht auf diese beschränkt, die je nach spezifischer Umsetzung, Standort und von Zeit zu Zeit abweichen können. Zwar kann die Arbeit eines Entwicklers in einem absoluten Sinn komplex und zeitaufwendig sein, doch wäre eine derartige Arbeit trotzdem ein routinemäßiges Vorgehen für einen Fachmann, der über den Vorteil dieser Offenbarung verfügt. Es muss klar sein, dass die hierin offenbarten und gelehrten Erfindungen für zahlreiche und verschiedene Modifizierungen und alternative Formen empfänglich sind. Schließlich ist die Verwendung eines Begriffs im Singular, wie beispielsweise „ein/eine“, die aber nicht darauf beschränkt wird, nicht dazu gedacht, die Anzahl von Elementen zu begrenzen.
• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• US 8176284 [0036]
• US 8176360 [0036]
• US 8443136 [0036]
• US 8631273 [0036]
• Zitierte Nicht-Patentliteratur
• Mattern, C., „Mixing Strategies in Data Compression“ in Data Compression Conference (DCC), 2012, Seite 337 bis 346 [0064]

Claims (20)

1. Verfahren für nicht binäre Kontextmischung in einem Komprimierer, aufweisend: ein Generieren, durch eine Mehrzahl von Kontextmodellen, von Modellvorhersagen in Bezug auf einen Wert eines nächsten Symbols, encodiert werden soll; ein Generieren, durch eine Mischeinrichtung, einer Gruppe von endgültigen Vorhersagen aus den Modellvorhersagen; und ein Generieren, durch einen arithmetischen Codierer, von komprimierten Daten auf Grundlage von empfangenen Eingabesymbolen und der Gruppe von endgültigen Vorhersagen, wobei die empfangenen Eingabesymbole zu einem Alphabet mit einer Größe gehören, die größer als zwei ist, und die Mischeinrichtung eine Feature-Matrix aus den Modellvorhersagen generiert und einen Klassifizierer schult, der die Gruppe von endgültigen Vorhersagen generiert.
2. Verfahren nach Anspruch 1, wobei der Klassifizierer ein Maximalentropie-Klassifizierer ist.
3. Verfahren nach Anspruch 1, wobei der Klassifizierer unter Verwendung von stochastischem Gradientenabfall geschult wird.
4. Verfahren nach Anspruch 1, wobei der Klassifizierer unter Verwendung von Minibatch-Gradientenabfall geschult wird.
5. Verfahren nach Anspruch 1, wobei der Klassifizierer unter Verwendung von Noise-Contrastive Estimation geschult wird.
6. Verfahren nach Anspruch 1, wobei die Mischeinrichtung ein neurales Netzwerk ist.
7. Verfahren nach Anspruch 1, wobei der Klassifizierer ein Maximalentropie-Klassifizierer ist, der unter Verwendung von stochastischem Gradientenabfall geschult wird.
8. Datenspeichersystem, aufweisend: einen Komprimierer für nicht binäre Kontextmischung, wobei der Komprimierer enthält: eine erste Mehrzahl von Kontextmodellen, die konfiguriert sind, um erste Modellvorhersagen in Bezug auf einen Wert eines nächsten Symbols zu generieren, das encodiert werden soll; eine erste Mischeinrichtung, die konfiguriert ist, um eine Gruppe von ersten endgültigen Vorhersagen aus den ersten Modellvorhersagen zu generieren; und einen arithmetischen Codierer, der konfiguriert ist, um komprimierte Daten auf Grundlage von empfangenen Eingabesymbolen und die Gruppe von ersten endgültigen Vorhersagen zu generieren, wobei die empfangenen Eingabesymbole zu einem Alphabet mit einer Größe von mehr als zwei gehören; und einen Dekomprimierer für nicht binäre Kontextmischung, wobei der Dekomprimierer enthält: eine zweite Mehrzahl von Kontextmodellen, die konfiguriert sind, um zweite Modellvorhersagen in Bezug auf einen Wert eines nächsten Symbols zu generieren, das decodiert werden soll; eine zweite Mischeinrichtung, die konfiguriert ist, um eine Gruppe von zweiten endgültigen Vorhersagen aus den zweiten Modellvorhersagen zu generieren; und einen arithmetischen Decodierer, der konfiguriert ist, um die empfangenen Eingabesymbole auf Grundlage der komprimierten Daten und die Gruppe von zweiten endgültigen Vorhersagen zu generieren, wobei die ersten und zweiten Mischeinrichtungen eine Feature-Matrix aus den ersten und zweiten Modellvorhersagen generieren und jeweilige Klassifizierer schulen, die die Gruppe von ersten und zweiten endgültige Vorhersagen generieren.
9. Datenspeichersystem nach Anspruch 8, wobei die Klassifizierer unter Verwendung von stochastischem Gradientenabfall geschult werden.
10. Datenspeichersystem nach Anspruch 8, wobei die Klassifizierer unter Verwendung von Minibatch-Gradientenabfall geschult werden.
11. Datenspeichersystem nach Anspruch 8, wobei die Klassifizierer unter Verwendung von Noise-Contrastive Estimation geschult werden.
12. Datenspeichersystem nach Anspruch 8, wobei die ersten und zweiten Mischeinrichtungen neurale Netzwerke sind.
13. Datenspeichersystem nach Anspruch 8, wobei die Klassifizierer Maximalentropie-Klassifizierer sind.
14. Datenspeichersystem nach Anspruch 8, wobei die Klassifizierer Maximalentropie-Klassifizierer sind, die unter Verwendung von stochastischem Gradientenabfall geschult werden.
15. Computerprogrammprodukt, wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium mit darauf verkörperten Programmanweisungen aufweist, wobei die Programmanweisungen durch einen Controller ausführbar sind, um den Controller zu veranlassen zu: einem Generieren von Modellvorhersagen in Bezug auf einen Wert eines nächsten Symbols, das encodiert werden soll; einem Generieren einer Gruppe von endgültigen Vorhersagen aus den Modellvorhersagen; und einem Generieren von komprimierten Daten auf Grundlage von empfangenen Eingabesymbolen und der Gruppe von endgültigen Vorhersagen, wobei die empfangenen Eingabesymbole zu einem Alphabet mit einer Größe gehören, die größer als zwei ist, und die Mischeinrichtung eine Feature-Matrix aus den Modellvorhersagen generiert und einen Klassifizierer schult, der die Gruppe von endgültigen Vorhersagen generiert.
16. Programmprodukt nach Anspruch 15, wobei der Klassifizierer unter Verwendung von stochastischem Gradientenabfall geschult wird.
17. Programmprodukt nach Anspruch 15, wobei der Klassifizierer unter Verwendung von Minibatch-Gradientenabfall und Noise-Contrastive Estimation geschult wird.
18. Programmprodukt nach Anspruch 15, wobei die Mischeinrichtung ein neurales Netzwerk ist.
19. Programmprodukt nach Anspruch 15, wobei der Klassifizierer ein Maximalentropie-Klassifizierer ist.
20. Programmprodukt nach Anspruch 15, wobei der Klassifizierer ein Maximalentropie-Klassifizierer ist, der unter Verwendung von stochastischem Gradientenabfall geschult wird.

Images