-
GEBIET DER ERFINDUNG
-
Ausführungsformen der Erfindung betreffen ein fehlertolerantes Trace-(bzw. Nachverfolgungs-)Tool, das zum Debuggen von Stromausfall-Unterbrechungsfehlern (PLI-Fehlern) für Festkörperlaufwerke (SSD) und Festplattenlaufwerke (HDD) verwendet wird.
-
ALLGEMEINER STAND DER TECHNIK
-
Ein Festkörperlaufwerk (SSD) ist eine Datenspeichervorrichtung, die integrierte Schaltungsanordnungen als Speichereinheiten verwendet, um anhaltend Daten zu speichern. Die SSD-Technologie verwendet elektronische Schnittstellen, die mit herkömmlichen Block-Eingabe-/Ausgabe-Festplattenlaufwerken (I/O-HDD) kompatibel sind. SSD setzen keine sich bewegenden mechanischen Komponenten ein, wodurch sie sich von den herkömmlichen HDD unterscheiden, die Daten auf sich drehenden Magnetscheiben durch Verwenden von beweglichen Lese-Schreib-Köpfen speichern.
-
Derzeit verwenden die meisten SSD NAND-basierte Flash-Speicher, die eine Form von nicht flüchtigen Speichern bilden, die Daten bei einem Stromausfall halten und die elektrisch gelöscht und neu programmiert werden können (weil der Flash-Speicher aus dem EEPROM entwickelt wurde). Weiterhin verbinden die hybriden Laufwerke die Merkmale von sowohl SSD als auch HDD in der gleichen Einheit, die typischerweise ein Festplattenlaufwerk und einen SSD-Zwischenspeicher enthält, um die Leistung von häufig verwendeten Daten zu verbessern. Der Flash-Speicher speichert Informationen auf einem Array aus Speicherzellen, die von Floating-Gate-Transitoren gebildet werden.
-
Auf Flash-Speicher (NAND) basierende Festkörperlaufwerke (SSD) sollen tolerant für Stromausfälle sein und verlieren keine Daten, wenn ein solcher Stromausfall auftritt. SSD weisen im Allgemeinen einen nicht flüchtigen Zwischenspeicher auf, in dem Daten gehalten werden, wie DRAM, wobei diese Daten im Fall eines Stromausfall-Ereignisses (PLI-Ereignis) in dem NAND-Speicher gespeichert werden müssen. Typischerweise enthält ein SSD Kondensatoren oder eine andere Speichervorrichtung mit einer absichtlich anhaltenden Ladung, die genügend Strom zum Speichern von Daten in den NAND bereitstellt, wenn ein PLI-Unterbrechungssignal empfangen wird. Die als Reaktion auf ein PLI-Ereignis gespeicherten Daten weisen typischerweise dirty Schreib-Zwischenspeicherdaten (also Daten, die anzeigen, ob der Block beim Ersetzen zurückkopiert werden muss) und LBA-Mappingtabelleninformationen auf (z. B. Indirektionstabellen), die Journalisierungsdaten aufweisen können.
-
PLI-Probleme erfordern jedoch typischerweise bedeutende Diagnoseanstrengungen, bei denen der Entwickler/Problemlöser in Besitz des Laufwerks sein muss, um Tools auf dem Laufwerk zum Beheben der Fehler, die während der Ausschaltabfolge aufgetreten sind, auszuführen. Je nach Schwere des Fehlers, bei denen ein Laufwerk typischerweise aufgrund einer Datenkohärenz-Unversehrtheitsprüfung beim Einschalten nicht „bereit” ist, kann dieser zu einem vollständigen Datenverlust führen, wobei die langen Diagnose-Durchlaufzeiten für die Kunden nicht zumutbar sind.
-
KURZDARSTELLUNG VON AUSFÜHRUNGSFORMEN DER ERFINDUNG
-
Ausführungsformen der Erfindung betreffen das Wiedergewinnen von Ereignisnachverfolgungsinformationen in Stromausfall-Unterbrechungsszenarien (PLI-Szenarien) für die Verwendung in Festkörperlaufwerk-(SSD) und Festplattenlaufwerk-(HDD)Speichervorrichtungen. Wenn zum Beispiel die DRAM-Statusinformation, die nach einem unbeabsichtigten Stromausfall gerettet wird, Ereignisnachverfolgungsinformationen enthielte, können solche Informationen eine wertvolle Debug-Ressource bereitstellen.
-
Gemäß einer Ausführungsform werden die Ereignisnachverfolgungsinformationen aus dem flüchtigen Speicher nach Einschalten als Reaktion auf ein PLI-Ereignis in einen zweiten Speicher kopiert. Ein beschädigter Status von in dem nicht flüchtigen Speicher gespeicherten Kontextrekonstruktionsdaten wird erkannt und eine Anzeige des beschädigten Status gesetzt. Gemäß einer Ausführungsform können die Ereignisnachverfolgungsinformationen, wenn dies basierend auf der Anzeige angefordert wird, an den Host weitergeleitet werden.
-
Bei einer optionalen Erweiterung werden als Reaktion auf eine Anforderung von einem Host die Ereignisnachverfolgungsinformationen an den Host zur Verwendung mit einem fehlertoleranten Debug-Tool weitergeleitet. Das Debug-Tool ist teilweise fehlertolerant, weil es zum Ableiten eines zulässigen Trace-Zeichens aus einem missgebildeten Trace-Zeichen konfiguriert ist.
-
Ausführungsformen, die in der Kurzdarstellung von Ausführungsformen der Erfindung beschrieben werden, sollen nicht sämtliche Ausführungsformen nahelegen, beschreiben oder lehren, die hierin beschrieben sind. Daher können die Ausführungsformen der Erfindung zusätzliche oder andere Merkmale als die in diesem Abschnitt beschriebenen enthalten.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Ausführungsformen der Erfindung sind in den Figuren der beiliegenden Zeichnungen beispielhaft und nicht einschränkend dargestellt, wobei ähnliche Bezugszeichen ähnliche Elemente bezeichnen. Die Figuren zeigen:
-
1 ein Blockdiagramm, das eine beispielhafte Betriebsumgebung darstellt, in welche die Ausführungsformen der Erfindung implementiert werden können;
-
2 ein Flussdiagramm, das ein Verfahren zum Retten von Ereignisnachverfolgungsinformationen bei einem Stromausfall-Unterbrechungsszenarium (PLI-Szenarium) gemäß einer Ausführungsform der Erfindung darstellt.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Ansätze für ein fehlertolerantes Trace-Tool, die zum Debuggen von Stromausfall-Unterbrechungsfehlern (PLI-Fehlern) in einer Festkörperlaufwerk(SSD)-Speichervorrichtung verwendet werden können, werden beschrieben. In der folgenden Beschreibung werden zum Zwecke der Erläuterung zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis der Ausführungsformen der hierin beschriebenen Erfindung bereitzustellen. Man wird jedoch erkennen, dass die Ausführungsformen der hierin beschriebenen Erfindung ohne diese spezifischen Details ausgeführt werden können. In einigen Beispielen sind gut bekannte Strukturen und Vorrichtungen in Form eines Blockdiagramms dargestellt, um die unnötige Verschleierung von Ausführungsformen der hierin beschriebenen Erfindung zu vermeiden.
-
FESTKÖRPERLAUFWERK-KONFIGURATION
-
Ausführungsformen der Erfindung können zum Verwalten einer Festkörperlaufwerk-Speichervorrichtung (SSD-Speichervorrichtung) verwendet werden. 1 ist ein Blockdiagramm, das eine beispielhafte Betriebsumgebung darstellt, in welche die Ausführungsformen der Erfindung implementiert werden können. 1 zeigt eine generische SSD-Architektur 100, wobei ein SSD 102 mit einer Host-Vorrichtung 104 über eine primäre Kommunikationsschnittstelle 106 kommunikativ gekoppelt ist. Ausführungsformen der Erfindung sind nicht auf eine Konfiguration wie die in 1 dargestellte beschränkt, die Ausführungsformen können vielmehr auch für andere Betriebsumgebungen als SSD angewendet werden, wie z. B. Festplattenlaufwerke (HDD), und können in andere als den in 1 dargestellten SSD-Konfigurationen implementiert werden. Zum Beispiel können Ausführungsformen zum Betreiben in anderen Umgebungen implementiert werden, die von flüchtigen Speicherkomponenten des Speichers für die vorübergehende Speicherung von wichtigen Betriebsinformationen abhängen.
-
Die Host-Vorrichtung 104 (oder einfach „Host”) repräsentiert grob jede Art von Computerhardware oder -software, die, unter anderem, Daten-I/O-Anforderungen oder -Anfragen an eine oder mehrere Speichervorrichtungen stellt. Zum Beispiel kann der Host 104 ein Betriebssystem sein, das auf einem Computer, einem Tablet-Computer, einem Mobiltelefon oder im Allgemeinen auf jeder Art Computervorrichtung ausgeführt wird, die einen Speicher enthält oder damit interagiert. Die primäre Schnittstelle 106, welche die Host-Vorrichtung 104 mit dem SSD 102 verbindet, kann zum Beispiel ein Internal Bus eines Computers oder ein Kommunikationskabel oder ein drahtloser Kommunikationsanschluss oder dergleichen sein.
-
Das beispielhafte SSD 102, das in 1 dargestellt ist, weist eine Schnittstelle 110, eine Steuerung 112 (z. B. eine Steuerung mit Firmware-Logik darin) und einen Adressierungsfunktionsblock 114, einen Datenpuffer-Zwischenspeicher 116, einen Fehlererkennungscode (ECC) 118 und eine oder mehrere nicht flüchtige Speicherkomponenten 120a, 120b, 120n auf. Der Adressierungsfunktionsblock 114, Datenpuffer-Zwischenspeicher 116 und ECC 118 können funktional als Teil der Steuerung 112 integriert sein, wie in einer System-On-Chip-Konfiguration (SOC-Konfiguration).
-
Die Schnittstelle 110 ist ein Ort der Interaktion zwischen den Komponenten, nämlich zwischen dem SSD 102 und der Host-Vorrichtung 104 in diesem Kontext, und ist sowohl auf Hardware- als auch Software-Ebene anwendbar. Dies ermöglicht einer Komponente, mit anderen Komponenten über ein Eingabe-/Ausgabe-System und ein zugehöriges Protokoll zu kommunizieren. Eine Hardware-Schnittstelle wird typischerweise über mechanische, elektrische und logische Signale an der Schnittstelle und dem Protokoll, das diese sequenziert, beschrieben. Einige nicht einschränkende Beispiele von herkömmlichen und Standard-Schnittstellen sind SCSCI (Small Computer System Interface), SAS (Serial Attached SCSI), und SATA (Serial ATA).
-
Ein SSD 102 weist eine Steuerung 112 auf, die eine Elektronik enthält, die nicht flüchtige Speicherkomponenten (z. B. NAND-Flash) zu dem Host überbrückt, wie den nicht flüchtigen Speicher 120a, 120b, 120n mit der Host-Vorrichtung 104. Die Steuerung umfasst typischerweise einen eingebetteten Prozessor, der den Code auf Firmware-Ebene ausführt.
-
Die Steuerung 112 weist eine Schnittstelle mit dem nicht flüchtigen Speicher 120a, 120b, 120n über den Adressierungsfunktionsblock 114 auf. Die Adressierungsfunktion 114 arbeitet zum Beispiel zum Verwalten von Mappings zwischen logischen Blockadressen (LBA) von dem Host 104 zu einer entsprechenden physikalischen Blockadresse des SSD 102, nämlich dem nicht flüchtigen Speicher 120a, 120b, 120n des SSD 102. Da die nicht flüchtige Speicherseite und die Host-Abschnitte unterschiedliche Größen aufweisen, muss ein SSD eine Datenstruktur bauen und halten, die das Übersetzen zwischen den von dem Host in den Abschnitt geschriebenen Daten oder das Lesen von Daten aus dem Abschnitt und der physikalischen nicht flüchtigen Speicherseite ermöglicht, auf denen die Daten zurzeit angeordnet sind. Diese Tabellenstruktur oder „Mapping” kann für eine Sitzung in dem flüchtigen Speicher 122 des SSD aufgebaut und aufrecht erhalten werden, wie ein DRAM oder eine andere lokale flüchtige Speicherkomponente, auf welche die Steuerung 112 und Adressierung 114 zugreifen können.
-
Die Adressierung 114 interagiert außer mit dem nicht flüchtigen Speicher 120a, 120b, 120n zusätzlich mit dem Datenpuffer-Zwischenspeicher 116 und dem Fehlerkorrekturcode (ECC) 118. Der Datenpuffer-Speicher 116 eines SSD 102 kann bei nicht einschränkenden Ausführungsformen SRAM oder DRAM als Zwischenspeicher verwenden. Der Datenpuffer-Zwischenspeicher 116 dient als Puffer- oder Staging-Bereich für die Datenübertragung zu und von den nicht flüchtigen Speicherkomponenten und dient als Zwischenspeicher zum Beschleunigen künftiger Anforderungen nach zwischengespeicherten Daten. Der Datenpuffer-Zwischenspeicher 116 ist typischerweise mit dem flüchtigen Speicher implementiert, sodass die darin gespeicherten Daten nicht permanent in dem Zwischenspeicher gespeichert sind, d. h. die Daten nicht persistent sind.
-
Der ECC 118 ist ein System zum Hinzufügen redundanter Daten oder Paritätsdaten zu einer Mitteilung, sodass diese von einem Empfänger sogar dann wiederhergestellt werden kann, wenn eine Reihe von Fehlern eingegeben wurde, entweder während des Übertragungsprozesses oder beim Speichern.
-
Schließlich weist das SSD 102 einen oder mehrere nicht flüchtige Speicherkomponenten 120a, 120b, 120n auf. Bei einem nicht einschränkendem Beispiel können die nicht flüchtigen Speicherkomponenten 120a, 120b, 120n als Flash-Speicher (z. B. NAND- oder NOR-Flash) oder als andere Typen Festkörperspeicher implementiert sein, die zurzeit oder in Zukunft zur Verfügung stehen. Die nicht flüchtigen Speicherkomponenten 120a, 120b, 120n sind die echten speicherelektronischen Komponenten, auf denen die Daten persistent gespeichert werden. Die nicht flüchtigen Speicherkomponenten 120a, 120b, 120n des SSD 102 können analog zu den Festplatten von Festplattenlaufwerk-Speichervorrichtungen (HDD-Speichervorrichtungen) angesehen werden.
-
Zusätzlich zu der SSD-Speichervorrichtung können Ausführungsformen der Erfindung auch zum Verwalten einer HDD-Speichervorrichtung verwendet werden. Zum Beispiel kann eine generische HDD-Architektur ein HDD umfassen, das kommunikativ mit einer Host-Vorrichtung über eine primäre Kommunikationsschnittstelle verbunden ist, ähnlich wie bei der SSD-Konfiguration 100 auf 1, bei der das SSD 102 mit dem Host 104 über eine primäre Kommunikationsschnittstelle 106 verbunden ist. Ferner weist das HDD eine Steuerung mit Firmware auf, die kommunikativ mit einem flüchtigen Speicher verbunden ist, ähnlich wie die Steuerung 112 und der flüchtige Speicher 122 des SSD 102. Der Vergleich zwischen den HDD-Komponenten und SSD-Komponenten ist als Konzept und nicht als identisch zu verstehen. Daher sei darauf hingewiesen, dass die HDD-Steuerungen anders als die SSD-Steuerung 112 sind, und ausgestaltet sind, um einige unterschiedliche sowie einige ähnliche Funktionen auszuführen. Sowohl HDD als auch SSD umfassen jedoch eine Steuerung mit darin eingebetteter/codierter Firmware, die mit einer Form von flüchtigem Speicher kommuniziert, zum Beispiel einem DRAM.
-
EINFÜHRUNG
-
Ausführungsformen der Erfindung werden nun mit Bezug auf Techniken zum Retten von Ereignisnachverfolgungsinformationen in einem Stromausfall-Unterbrechungszenarium (PLI-Szenarium) beschrieben. Die Ausführungsformen können für Festkörperlaufwerk-Speichervorrichtungen (SSD-Speichervorrichtungen) und Festplattenlaufwerk-Speichervorrichtungen (HDD-Speichervorrichtungen) verwendet werden und darin implementiert sein. Entsprechend ermöglicht die Verwendung dieser Techniken den Erhalt eines nutzbaren Trace von dem Kunden-HDD- oder -SSD-Laufwerk mithilfe eines einzelnen Speicherauszugs und verhindert, dass der Kunde das Laufwerk ins Werk zur Analyse einsenden muss. Die Rettung von Ereignisnachverfolgungsinformationen ist typischerweise bei nicht einschränkenden Beispielen für die Firmware-Entwicklung und Laufwerkvalidierungs- und -qualifizierungsprüfungen relevant und anwendbar.
-
Ein herkömmlicher Code-Debugging-Prozess für eingebettete Systeme ist im Allgemeinen das Durchführen eines Speicherauszugs, der eine Abbildung des Status des internen Systemspeichers wie eines Anweisungsspeichers, Datenspeichers, DRAM und dergleichen ist. Grundsätzlich würde diese Abbildung den Status des Systems bereitstellen, den ein Entwickler oder Debugger dazu verwenden kann, um ein Problem innerhalb des Systems zu verstehen. Solche Speicherauszüge werden typischerweise entweder periodisch oder als Reaktion auf ein Unterbrechungsereignis durchgeführt.
-
Eine relativ neue Klasse von Problemen ist, dass ein Firmware-Entwickler die Firmware benötigt, um ein PLI-Ereignis und eine entsprechende Reaktion und Wiederherstellung zu unterstützen. Zum Beispiel würde eine Hilfe für ein PLI-Ereignis normalerweise das Handhaben von „dirty” Schreibdaten benötigen, die schreibzwischengespeichert wurden und von dem Host bereits anerkannt wurden, aber noch nicht in den nicht flüchtigen Medien gespeichert wurden. Zusätzlich besteht bei SSD der Bedarf nach dem Speichern von Indirektionsdatentabellen, die logische Datenadressen an physischen Speicherorten mappen. PLI-Ereignisse sind vorübergehend und unerwartet wodurch sich der entsprechende Support für solche Ereignisse als ein nicht trivialer und herausfordernder Prozess darstellt. Daher reagiert die Firmware im ersten Augenblick nicht immer optimal auf ein PLI-Ereignis.
-
Entsprechend sind die Firmwarenachverfolgungsinformationen eines der wertvolleren Debug-Tools für einen Entwickler. Die Ereignisnachverfolgungsinformationen sind mit einem Log verknüpft, das Ausführungsinformation im Zusammenhang mit den vorherigen hunderten oder tausenden von ausgeführten Befehlen auflistet. Die Nachverfolgungsinformationen können zum Beispiel die Identifizierung der letzten ausgeführten Codelinie, Codevariablen und dergleichen beinhalten, die allesamt wichtige Informationen für einen Debugger darstellen. Die Speicherauszüge priorisieren jedoch typischerweise Firmware-Datenstrukturen und möglicherweise Benutzerdaten, die Nachverfolgungsinformationen werden hingegen als Informationen von geringerer Priorität zum Ausziehen aus einem System bei Systemfehler behandelt.
-
Daher können Nachverfolgungsinformationen niemals persistent gespeichert werden, weil der kurzfristig aufrecht erhaltene Strom, der zum Verarbeiten verfügbar ist, wenn ein System einen Stromausfall erleidet, nicht einmal ausreichen kann, um die Nachverfolgungsinformationen abzurufen.
-
Wie beschrieben sind einige Nachteile konventioneller Speicherauszugsprozesse die regelmäßige Durchführung von Speicherauszügen und die Priorisierung von Datenstrukturen und Benutzerdaten. Außerdem kann es vorkommen, dass Systemfehler bei einer oder mehreren unterbrochenen Sequenzen deaktiviert werden und daher keine Statusdaten persistent gespeichert werden.
-
DYNAMISCHER SCHREIB-LESESPEICHER (DRAM)
-
Ein DRAM besitzt einige interessante inhärente physische Eigenschaften. Obgleich er als flüchtig angesehen wird, weist der DRAM über einen relativ kurzen Zeitraum hinweg tatsächlich einige Merkmale eines nicht flüchtigen Speichers auf. Das heißt, dass nach dem Aus- und Einschalten eines Systems der interne DRAM seinen Status einen gewissen Zeitraum ohne Strom halten kann, zum Beispiel möglicherweise bis zu 30 Sekunden bis hin zu einigen Minuten. Einige Bits können fallengelassen oder vertauscht werden, aber die Daten in dem DRAM sind immer noch relativ intakt für den Zeitraum unverzüglich nach einem Stromausfall. Ferner kann ein Steuerungsspeicherverwalter ECC-Schutz für den DRAM einsetzen (Einzelbitkorrektur, Doppelbiterkennung), der einige Fehler in den Daten korrigieren kann.
-
VERFAHREN ZUM RETTEN VON EREIGNISNACHVERFOLGUNGSINFORMATIONEN
-
Basierend auf der vorstehenden Eigenschaft des DRAM kann während eines Einschaltens nach einem Ausschalten, wobei das Einschalten normalerweise innerhalb weniger Sekunden nach Ausschalten erfolgt, der DRAM-Status im Wesentlichen in der Zeit bis zu dem Zeitpunkt des Ausschaltens und zu der letzten DRAM-Auffrischung zurückgehen. Falls die DRAM-Statusinformationen, die nach einem unbeabsichtigten Stromausfall gerettet werden, Ereignisnachverfolgungsinformationen enthielten, könnten solche Informationen eine wertvolle Debug-Ressource bereitstellen. Zum Beispiel können solche Ereignisnachverfolgungsinformationen verwendet werden, um zu verstehen und zu debuggen, wie Firmware auf bestimmte Ereignisse reagiert, nämlich auf Fehlerereignisse wie einen Stromausfall-Unterbrechungsfehler.
-
2 ist ein Flussdiagramm, das ein Verfahren zum Retten von Ereignisnachverfolgungsinformationen bei einem Stromausfall-Unterbrechungsszenarium (PLI-Szenarium) gemäß einer Ausführungsform der Erfindung darstellt. Der in 2 dargestellte Prozess kann in einem SSD wie SSD 102 (1) implementiert werden. Genauer kann gemäß einer Ausführungsform der Prozess aus 2 in der Steuerung 112 (1) des SSD 102 implementiert werden. Die Prozesslogik kann als analoge oder digitale Hardwareschaltung in dem SSD 102 implementiert sein oder vorzugsweise als Firmware-Anweisungen, die von einem Prozessor ausgeführt werden, wie von der CPU 204 (2) oder einer MPU im SSD 102.
-
Bei Block 202 aus 2 werden die Ereignisnachverfolgungsinformationen aus dem flüchtigen Speicher in einen zweiten Speicher kopiert. Zum Beispiel werden Ereignisnachverfolgungsinformationen von dem flüchtigen Speicher 122 (1) in einen dedizierten Abschnitt des flüchtigen Speichers 122 oder in einen oder mehrere nicht flüchtige Speicher 120a, 120b, 120n (1) kopiert. Das Kopieren von Ereignisnachverfolgungsinformationen von dem flüchtigen Speicher in den zweiten Speicher wird beim Einschalten durchgeführt, das in einer Ausführungsform als Reaktion auf ein Stromausfall-Unterbrechungsereignis folgt. Dies ist ein optimaler Zeitpunkt zum Kopieren der Ereignisnachverfolgungsinformationen in den Speicher, bevor die Daten nach dem als Reaktion erfolgenden Einschalten zurückgesetzt oder überschrieben werden, weil die aktuellsten Informationen erneut erfasst werden, d. h. jede Bearbeitung widerspiegelt, die seit dem letzten periodischen Speichern von Traces stattgefunden hat. Weiterhin findet das Kopieren dieser Ereignisnachverfolgungsinformationen bei einem „kalten” Reset statt, bei zuvor abgeschaltetem Strom, statt bei einem „warmen” Reset, das nicht als Reaktion auf ein Stromausfall-Szenarium erfolgt.
-
Bei Block 204 wird ein beschädigter Status der Kontextrekonstruktionsdaten, die in dem nicht flüchtigen Speicher gespeichert sind, erkannt. Typischerweise versucht die Firmware bei einer Einschaltabfolge, ihren Status basierend auf den Informationen, die von den nicht flüchtigen oder persistenten Medien verfügbar sind, zu rekonstruieren. Dieser Prozess wird hierin als Kontextrekonstruktion bezeichnet, weil die Firmware versucht, den Kontext oder Status der Ausführung zum Zeitpunkt des Fehlers zu rekonstruieren. Ferner ist die Firmware zum Erkennen eines beschädigten Datenstatus konfiguriert, der programmiert wird, um für Rekonstruktionszwecke verwendet zu werden. Bei nicht einschränkenden Beispielen kann die Firmware erkennen, dass sie die Indirektionstabellen (LBA) nicht vollständig rekonstruieren kann oder dass „dirty” Schreibdaten, die nicht in den persistenten Speicher geschrieben wurden, oder dergleichen vorliegen.
-
Bei Block 206 wird eine Anzeige des beschädigten Status gesetzt. Zum Beispiel kann beim Erkennen eines beschädigten Datenstatus die Firmware eine Flag oder ein Bit setzen, die bzw. das einen beschädigten Status anzeigt. Durch Setzen dieser Anzeige teilt die Firmware dem Host effektiv den beschädigten Status mit, weil der Host auf die Anzeige als gesetzt zugreifen und diese lesen kann. Zum Beispiel kann ein speichervorrichtungsexternes Programm (z. B. ein Test- oder Validierungsprogramm) die Flag lesen und die Ereignisnachverfolgungsinformationen seit dem Zeitpunkt des PLI-Ereignisses von der Speichervorrichtung für den Host anfordern. Es sei darauf hingewiesen, dass dies kein guter Zeitpunkt zum Speichern der Ereignisnachverfolgungsinformationen in dem nicht flüchtigen Speicher ist, weil der Speicherprozess den derzeitigen Informationsstatus tatsächlich verändern kann.
-
Bei Block 208 werden die Ereignisnachverfolgungsinformationen als Reaktion auf eine Anforderung von dem Host oder einem Anwendungsprogramm, das auf dem Host ausgeführt wird, weitergeleitet, zum Beispiel als Reaktion auf eine Anzeige eines beschädigten Status. Diese Informationen können durch Verwenden der herkömmlichen Speichervorrichtungsschnittstelle (z. B. SAS) weitergeleitet werden, oder über eine Seitenband-Debug-Schnittstelle.
-
FEHLERTOLERANTES DEBUG-TOOL
-
Für einen Debug-Prozess kann im Wesentlichen jede beliebige Menge von zulässig gebildeten Nachverfolgungsinformationen für das Bereitstellen eines gewissen Einblicks in das zu analysierende Problem hilfreich sein. Je mehr zulässig gebildete Nachverfolgungsinformationen also verfügbar sind, desto besser kann die Problemanalyse durchgeführt werden.
-
Gemäß einer Ausführungsform können die Ereignisnachverfolgungsinformationen an ein fehlertolerantes Debug-Tool weitergegeben werden, das auf einem Host ausgeführt werden kann. Bei dem Debug-Tool handelt es sich um ein Nachbearbeitungs-Tool, das Ereignisnachverfolgungsdaten parst und analysiert. Obgleich die Ereignisnachverfolgungsinformationen im Allgemeinen perfekt gebildet sind, sollte ein robustes Debug-Tool für missgebildete Ereignisnachverfolgungsinformationen und -Zeichen tolerant sein. Ein solches Debug-Tool ist fehlertolerant, zumindest teilweise, sodass das Tool seine Bearbeitung auch dann fortsetzt, wenn es beschädigte Daten findet, und sollte intelligente Annahmen über missgebildete Informationen zum Erreichen eines „bestmöglichen Ratens” vornehmen können, wie die missgebildete Information bei zulässiger Bildung gewesen wäre. Alternativ und möglicherweise typischer werden die Nachverfolgungsinformationen nach deren Erhalt (normalerweise durch einen qualifizierten Techniker an dem Kundenlaufwerk) an das SSD-Entwicklungsteam weitergeleitet und offline geparst.
-
Gemäß einer Ausführungsform umfasst das fehlertolerante Debug-Tool eine Inferenz-Engine, die zum Ableiten eines zulässigen Trace-Zeichens aus einem missgebildeten Trace-Zeichen konfiguriert ist. Diese Inferenz basiert auf der Annahme oder Erkenntnis, dass jedes Bit, das Ereignisnachverfolgungsinformationen repräsentiert, normalerweise von einer „1” zu einer „0” zerfällt, während das System und der konstituierende flüchtige Speicher aufgrund des PLI-Ereignisses Energie verlieren. Die exakte Implementierung einer solchen Fehlertoleranz in ein Debug-Tool variiert basierend auf zahlreichen Faktoren, wie basierend auf der Implementierung der entsprechenden Firmware, basierend auf der Bildung der entsprechenden Ereignisnachverfolgungsinformationen und basierend auf der Implementierung des Debug-Tools selbst und dergleichen.
-
In der vorgenannten Spezifikation wurden Ausführungsformen der Erfindung mit Bezug auf zahlreiche spezifische Details beschrieben, die je nach Implementierung unterschiedlich sein können. Daher ist der einzige und wahre Indikator dafür, was die Erfindung ist, und was von den Anmeldern als Erfindung bezweckt wird, der Satz von Ansprüchen, die aus dieser Anmeldung hervorgehen, in der spezifischen Form, in der diese Ansprüche vorliegen, und schließt jede mögliche nachfolgende Korrektur ein. Sämtliche Definitionen, die hierin ausdrücklich für Begriffe gesetzt wurden, die in den Ansprüchen enthalten sind, führen die Bedeutung solcher Begriffe, wie in den Ansprüchen verwendet, an. Daher kann keine Einschränkung, Element, Eigenschaft, Merkmal, Vorteil oder Attribut, die nicht ausdrücklich in einem Anspruch zitiert werden, den Umfang dieses Anspruchs auf keine Weise einschränken. Die Beschreibung und die Zeichnungen sind dementsprechend im veranschaulichenden und nicht im einschränkenden Sinne zu verstehen.
